urandom (steve-parker.org)

Copyright in the USA

uRandom - Steve-Parker.org — Wed, 01 Feb 2012 15:56:30 -0800

An excellent recent talk, made just before the PIPA and SOPA acts were derailed, which gives a succinct history of the last 20-30 years of media lobbying in the USA.

http://youtu.be/9h2dF-IsH0I

rm -rf /

uRandom - Steve-Parker.org — Tue, 31 Jan 2012 15:08:52 -0800

It is commonly said that Solaris 10 will not allow you to issue a rm -rf / command. Few get to try it, but it was being discussed in the office today, so I thought I'd try it on a virtual machine.

The classic rm -rf / gets the message "rm of / is not allowed" and a return code of 2. Some variations get the same, whilst others (such as cd /; rm -rf .) get no message, a return code of zero, but nothing happens. Here is a transcript:

$ ssh sunflare

Password:

Last login: Tue Jan 31 21:38:05 2012 from goldie

Oracle Corporation SunOS 5.10 Generic Patch January 2005

steve@sunflare:~$ su -

Password:

Oracle Corporation SunOS 5.10 Generic Patch January 2005

# bash

root@sunflare:/# df -h

Filesystem size used avail capacity Mounted on

/dev/md/dsk/d10 9.6G 3.6G 5.9G 38% /

/devices 0K 0K 0K 0% /devices

ctfs 0K 0K 0K 0% /system/contract

proc 0K 0K 0K 0% /proc

mnttab 0K 0K 0K 0% /etc/mnttab

swap 2.1G 992K 2.1G 1% /etc/svc/volatile

objfs 0K 0K 0K 0% /system/object

sharefs 0K 0K 0K 0% /etc/dfs/sharetab

fd 0K 0K 0K 0% /dev/fd

swap 2.1G 72K 2.1G 1% /tmp

swap 2.1G 32K 2.1G 1% /var/run

/dev/md/dsk/d60 4.6G 4.7M 4.6G 1% /export/home

root@sunflare:/# rm -rf /

rm of / is not allowed

root@sunflare:/# echo $?

2

root@sunflare:/# cd /usr

root@sunflare:/usr# rm -rf ../

rm of / is not allowed

root@sunflare:/usr# cd /tmp

root@sunflare:/tmp# rm -rf ../

rm of / is not allowed

root@sunflare:/tmp# cd /usr/sfw/bin

root@sunflare:/usr/sfw/bin# rm -rf ../../..

root@sunflare:/usr/sfw/bin# cd /

root@sunflare:/# rm -rf .

root@sunflare:/# echo $?

0

root@sunflare:/# pwd

/

root@sunflare:/# df -h .

Filesystem size used avail capacity Mounted on

/dev/md/dsk/d10 9.6G 3.6G 5.9G 38% /

root@sunflare:/# cd /dev

root@sunflare:/dev# rm -rf ../tmp/../

rm of / is not allowed

root@sunflare:/dev# rm -rf ../tmp/..

root@sunflare:/dev# exit

steve@sunflare:~$ logout

Connection to sunflare closed.

$

Binary (In)Compatability: Solaris 11 : A Response

uRandom - Steve-Parker.org — Wed, 25 Jan 2012 15:08:36 -0800

An article on rootvg.net, Binary (In)Compatability: Solaris 11, claims that in the Oracle Solaris 11 ISV Adoption Guide, the Executive Overview says, simply - Q. quaranteed? A. not any longer. This is actually a paraphrase. The later quote is correct:

This document is designed to help independent software vendors (ISVs) transition their applications smoothly from Oracle Solaris 10 to Oracle Solaris 11. It provides a list of all currently known modifications, which may be needed for existing applications to run on Oracle Solaris 11. The majority of applications will work without any modification.

Actually, this document explains issues beyond the ABI; as new features are introduced, and previously deprecated functions are removed, the operating environment will change. The ABI is still guaranteed, however.

What the document does cover are listed clearly:

It discusses the currently known border cases where configuration changes may be needed due to:

Modified default configurations and settings (examples: default shells, ZFS root file system)

Retired packages (example: obsolete physical devices)

Evolution of industry standards (example: standardized locale names)

Removal of already-deprecated functions

Removal of undocumented and unsupported functionality

Border cases introduced by new technologies (such as ZFS root file system default)

Bug fixes and increased security (narrower access and usage rights)

The new installation technology known as Image Packaging System (IPS)

The document clearly states that Oracle Solaris 11 and Oracle Solaris 11 are planned to be binary compatible with previous Oracle

Solaris versions2. This means that existing application binaries should run on Oracle Solaris 11 (and higher) without recompilation, as long as that applications were coded to standard, published Oracle Solaris APIs and ABIs. Presumably the repetition of "Oracle Solaris 11" is a typo related to the removal of OpenSolaris, though that is just a guess on my part.

So - the binary compatibility guarantee is the same as it always has been. Software which makes assumptions about older versions of Solaris may need checking - parsing the output of "df" is different for ZFS filesystems. Using the pkginfo command to check availability of a software package won't work for IFS packages. Depending on an obsolete driver would also make no sense, just as AIX6 does not support POWER3 architecture, for example.

The document further clarifies the situation - same as it ever was:

Oracle Solaris provides a binary guarantee – that an application that complies with the Oracle Solaris ABI developed and built on an earlier version of Oracle Solaris should run unmodified on Oracle

Solaris 11 on the same architecture. In order to provide this guarantee, the application must meet the following restrictions:

The application must be dynamically linked - neither the application nor any of its component libraries should statically link any of the Oracle Solaris system libraries.

The application must use only API functions that are documented as committed, standard or stable.

Interface stability is described in the attributes(5) man page.

The application must not use uncommitted, unstable or evolving API interfaces.

The application must not use private or undocumented interfaces.

Oracle Solaris provides a number of tools to check an application’s compliance against the Oracle Solaris ABI.

On Oracle Solaris 10 the appcert and apptrace tools can be used to perform static and dynamic checking of an application to test for ABI compliance. This can be done a system running Oracle Solaris 10 before testing the application on Oracle Solaris 11.

The Oracle Solaris Ready Test Suite, used on Oracle Solaris 10 to determine if an application can be deployed in a zone, includes an ABI compliance check.

The document also goes into some detail of changes in Solaris Zones; one of the biggest is that Branded Zones for Solaris 8 and Solaris 9 are no longer supported, but as they were never supported for production use, that is of very little relevance.

So, the Solaris binary compatibility guarantee is just as healthy as it has ever been.

The RootVG.net article suggests that the answer is to "use shared libraries and API's. The new shared libraries do the work, should it be necessary, to make it work." Clinging to the past, whilst adding complexities to library code is not the way to deal with the huge feature changes and massive development work that has happened in Solaris 10 and Solaris 11. Maintaining a clear and supported ABI is the solution. Solaris has always done that, and continues to do that, whilst also maintaining Unix as a first-class 21st century operating system.

OpenOffice.org / LibreOffice Migration Guide for Microsoft Office Users

uRandom - Steve-Parker.org — Thu, 22 Dec 2011 01:20:29 -0800

There is a fairly detailed Migration Guide on the OpenOffice.org Wiki, which although quite old still looks very good.

I'm surprised that I have never come across this, as it is a great piece of marketing for OpenOffice.org and LibreOffice, but seems to have had little publicity. There are individual pages comparing general differences, the word processor, spreadsheet and presentation parts of the respective office packages, as well as more general usage information

Solaris Packaging with Zones

uRandom - Steve-Parker.org — Tue, 20 Dec 2011 00:48:28 -0800

One handy use for Solaris Zones that I have come across recently, is a very quick and easy way to build packages. Rather than "polluting" the main filesystem tree with the software to be packaged, simply create a zone, install the software there, and as a final act, you can even prune unwanted parts of the tree before packaging it up and disposing of the zone.

I had some software to install into /usr/local; the existing tree includes some (non-essential) software already in /usr/local, so I created a full-root zone, cleaned /usr/local within the zone, built the software (configure && make && make install), which was actually Perl, some third-party libraries, and 30 or so modules, and tested it in the zone.

Then to package it up, simply drop back to the global zone:

# cd /tmp/pkg


# echo "i pkginfo" > prototyp


# pkgproto /zones/myzone/root/usr/local=/usr/local >> /tmp/pkg/prototype


# cat - > pkginfo << EOF


NAME=Perl Stuff


PKG=MYperl


CLASSES=none


PSTAMP=


VERSION=5.8.9


EOF


# pkgmk

The package is ready in /var/spool/pkg/MYperl. You can use pkgtrans to ocnvert this into a MYperl.pkg file.

Command of the day

uRandom - Steve-Parker.org — Thu, 15 Dec 2011 04:33:38 -0800

chown -h changes the ownership of symbolic links (rather than what they point to)

Solaris 10 releases, by date and update number, and associated kernel patch

uRandom - Steve-Parker.org — Thu, 08 Dec 2011 00:55:54 -0800

Solaris 10 kernel patches along with their associated Solaris 10 release dates and numbers

Gnome in CentOS 6

uRandom - Steve-Parker.org — Tue, 06 Dec 2011 08:34:04 -0800

In CentOS6 (and presumably RHEL6, though I haven't tried it), if you do a minimal install and then add gnome-desktop, it will not pull in everything that is needed:

xorg-x11-server-Xorg

gnome-session

gnome-power-manager

gnome-session-xsession

gnome-panel

That's enough to get you logged in.

Then you'll still need gnome-terminal and all the other essential tools.

Presumably there is some meta-RPM in RHEL6 which pulls all of these in, but surely at a minimum, gnome-session should pull in gnome-session-xsession (which only contains one file: /usr/share/xsessions/gnome.desktop)

Notes on Anacron

uRandom - Steve-Parker.org — Wed, 30 Nov 2011 15:22:29 -0800

Traditional cron works as on Solaris. On RHEL5/OEL5 this is vixie-cron. On RHEL6, it's cronie.

RHEL5 Notes

RHEL6 Notes

Anacron runs on boot (in case it needs to run tasks now - such as if it had a 2am job and gets shutdown overnight). It used to get called by the regular cron, it is now controlled by /etc/anacrontab

/etc/anacrontab tells anacron to run cron.daily at "1 65 cron.daily" - ie, every 1 day, after 65 minutes - ie, 0105AM.

Similarly cron.weekly is run at "7 70" - do the weekly jobs at 0110AM every 7 days.

cron.monthly is run at "30 75" - every 30 days at 0115AM.

So, this mechanism controls when (on a typical system, up 24/7) the cron jobs get run.