Archive for the ‘Solaris’ Category

Requirements For A Usable Package Manager

Jeff writes:

What I would like to explain is why the impedance mismatch between Linux and Solaris packaging is not so much a technological divide as it is a philosophical one.

Philosophical differences are fine. Infinite diversity in infinite combinations, etc., however, regardless of the philosophy the goal of the package manager should be to make the life of the sysadmin easier, otherwise it’s not much use.

For a change this won’t be a rant about how the package set is an ancient pile of crap, we’ll assume for the sake of this discussion that you’re so concerned about stability you’re willing to live with a 6 year old version of bash. We won’t discuss how incompatible 3rd party sites are a poor substitute for the ports tree, because maybe you’re happy with a 5 year old version of nano.

The point is the tools should be independent of the packaging philosophy. They should minimise the amount of effort required to manage the system – automation is a good thing ™. On that basis, I propose that there is a minimum set of functions these tools should provide.

  • Automatic Dependency Resolution. Pretty obvious, you can’t call anything a package manager if it can’t do this.
  • Simple Upgrade. All upgrades to the packages should of course be available as packages, and there should be a simple command to upgrade all packages for which there is a new version (thanks Cian for reminding me of this one)
  • Remote Repo Support. HTTP is preferable for this, because, everyone has a http server. I don’t want to carry the Solaris 10 DVD in my pocket everywhere, and I don’t want to go around mounting NFS directories. The vendor doesn’t have to provide the package server, just support in the tools for a package server so I’m free to make my own (and, so are others)
  • Support For Multiple Repos. Blastwave has it’s own tools (yes, multiple) to actually install it’s packages. SunFreeWare relies on you doing your own manual dependency resolution (*shudder*). This is a load of shite. The package tools supplied by the operating system should allow me to define multiple sources, and rules for which source should be used. I should be free to build custom packages with dependencies against base packages if that’s what I choose (and, there’s lots of reasons to want to do this), or to maintain a separate hierarchy of independent software (like blastwave etc.) if that’s what the situation requires.
  • Simple tools to query packages, search for packages, query files. We don’t need all the bells and whistles of apt, but, we do need equivalents for ‘apt-cache search’, ‘yum info’, and ‘dpkg -S’.

Regardless of the philosophy, the point of a package manager should be to manage all the software on the system. I don’t have time to compile things, and I don’t enjoy patching things. There is no reason that you can not achieve separation of components, (eg, base and ports) while still providing binary packages for everything. The whole system should be package managed, apart from the handful of shell scripts I have sitting in /usr/local/bin ( the one place the package manager should never touch. /usr/local/ is for me to manage. This is what both FHS and the debian package policy says)

Solaris, Syslog & Syslog-ng

Recently I setup a Solaris 10 box logging to a syslog-ng loghost, using the standard solaris syslog.

I found loads of docs on how to build syslog-ng on solaris, but I decided I’d rather avoid that – don’t really need any of the extra features here.

# /etc/syslog.conf Configuration file for syslogd.
# First some standard logfiles. Log by facility.
# /var/log/auth.log
*.info /var/log/syslog /var/log/daemon.log /var/log/kern.log /var/log/lpr.log /var/log/mail.log /var/log/user.log
# cron seems to log to /var/cron/log rather than syslog, so
# /var/log/cron.log should be a symlink to that.
# /var/log/cron.log
# Some `catch-all' logfiles.
*.debug;news.none;mail.none;auth.none /var/log/debug
*.info;*.notice;*;warn;auth;cron,daemon.none;mail,news.none /var/log/messages
# Emergencies are sent to everybody logged in.
*.emerg *
# Remote logging
# Send everything except auth.debug to sprout
*.debug; @log.internal

This is the syslog.conf I ended up with. The stock solaris one wasn’t very readable, so I ended up throwing it away and starting again. I took the default syslog.conf from a debian box instead, and used that as a basis for starting with (since we’re all much more familiar with debian I prefered having the logs in debian like locations).

The biggest change I had to make was that where debian had used a wildcard to indicate any level here I had to specify the lowest level to include – including this level also includes any level of a higher priority.

The last line covers sending the logs to our remote syslog-ng host, sending it all lines except auth.debug (that seemed to be VERY long). Log.internal is specified in the /etc/hosts file.

This worked fairly well on the loghost. Solaris uses UDP to send syslog messages, where as we usually use TCP, but setting syslog-ng up to accept these too wasn’t a problem. It doesn’t however send the hostname, so you’ll need to setup syslog-ng to look these up, or you’ll just get ip addresses everywhere.

The man page for syslog.conf is actually fairly helpful – this one bit in particular is worth mentioning..

A filename, beginning with a leading slash, which indicates that messages specified by the selector are to be written to the specified file. The file  is  opened  in append  mode  if it exists. If the file does not exist, logging silently fails for this action.