Recently in SysAdmin Category

Here are some variants that I've seen so far.

1. Careful people that are afraid to spoil the system use:

   • /usr/local
   • /var/local
   • /opt

2. Crazy people have always an original place to hide files in:

   • /usr/local64
   • /usr/local/64
   • /usr/local/local
   • /shared
   • /corp
   • /data
   • ...

3. Linux distributions put files according to the Filesystem Hierarchy Standard.

Some years ago I belonged to the first group and I was putting everything into /usr/local to be sure that there is just my stuff. Today I belong to the second one... I use /data for my laptop. Which is not so great idea, but it is my laptop and no one ever will have to (won't even be able) to touch it, so it is my mess. Some of the other ones like /corp, /shared and /usr/local64 I have to use at $work, because it is ops decision or a historical reason (sniff, sniff).

I hope one day I'll further evolve to work according to the standards. Tiding-up my mess would be the easy part of the journey...

Once upon a time I was a young system administrator. Having all the strange looking /usr, /var, /etc, ... all round me was scary and I was not sure what to "do" with all those folder trees. At some point I started to compile the extra programs that I needed. With a default prefix all ended up in /usr/local which looked safe to me. I knew that my stuff is there and the mysterious system stuff is everywhere else.

Well it worked. Having to maintain some more servers later I started to do some packaging. I was using Slackware at that time and the Slackware packaging system was really simple - just a tarball that got extracted to the root of the file system with some scripts that got executed during the package installation time. Simple and worked for me. Still I kept the stuff in /usr/local to be on the safe side.

And the time passed :-) and I'm using Debian now, but most important change is that I've lost all my respect to the file system and I've learned where and why to put files. Why to use /etc for configs, /var/log for logfiles, /var/lib for state files, /var/cache for cache files, /usr/share for templates or static data files, etc.? Simple because it is standard. Because it is standard, standard compliant distribution will stick to it. Besides being standard there are some really good reasons too. Helper tools will understand the files and then act based on the files category. Automatically rotating logs, backup-ing the important (non static distribution) files, cleaning up the temporary files etc. Well and there are also humans out there. Co-admins or newcomers, that will login to the machine and look for files or trouble shoot the programs. Knowing where to look for stuff really helps!

With today advance of virtualization techniques there is no reason to mix too many things (projects) on one server. So there is no reason to play safe with the paths and files should be put to the right place where they belong - FHS.

Reply to two commanets from "when virtualization is too expensive".

1st was from grantm. Thanks for pointing out the OpenVZ. It's much more professional tool than debootstraping and chrooting, but comes with more configuration and setting-up complexity. It's possible to share memory using OpenVZ which is the resource that we never have enough.

2nd was from Alias. Alias is pointing out the deduplication of disk data. Disk space is kind of cheep these days, comparing to memory, bandwidth and cpu processing costs when dealing with huge data. The deduplication can offer, besides saving the disk space, a better cache efficiency, that will increase disk read speed, that is never fast enough. ZFS should soon (first quarter of 2010) support deduplication. It seems that there will be no native ZFS support for Linux because of the licencing problems :-( . Easy Linux deduplication that can come in handy is cowdancer. `cp -al some-folder/ some-folder.copy && cd some-folder.copy && cow-shell` will copy "some-folder" via creating hardlinks which is really fast. Than any write operation under this shell and folder will result in removing the hardlink and creating a new file => copy-on-write. This works good with chroot-ed systems.

Yes the thing that turns your single computer to multiple computers. Why should it be expensive? Simply because the virtual machines are not sharing one disk space and one memory. To make the the virtual system run smoothly, it needs some decent amount of dedicated memory and a disk volume with some reserve so it doesn't have to be resized too often.

First find the reasons for doing virtualization, why would anyone want to run multiple machines on a single hw? Most likely to clearly separate the programs and the whole operating systems. Give the strictly defined virtual hw resources, limit the access for security reasons. And also to add one level of abstraction which then allows systems to live in a cloud. But that is a different topic.

Let's search for the solutions how not to do virtualization and fulfil some (!) of the requirements of it. Mainly the clear files and whole system separation for Perl development.

If just Perl is in the play, then compiling and installing user own Perl is an option. Simply having the Perl binary and all the installed CPAN modules in the $HOME directory of the user.

If Apache is needed or some extra binary libraries, it is still possible to compile and install to the user home, but it is quite a lot of "hand work" and not every one has time and passion to do it. Much more simple way is to use chroot. What chroot does is that it sets root of the filesystem for the child processes to a folder. And as we are in UNIX, where (nearly) anything is a file, this means a different machine. Both systems, the parent and the chroot-ed, still share the same /proc, /dev, network devices etc., but the separation is enough to be able to install programs with standard distribution commands and run them. Fair enough to have chroot-ed machine as a development machine. Benefiting of shared memory and disks pace, easy file sharing (one filesystem) and not having to maintain virtualization sw.

Here is how to create a chrooted system on Debian and switch to it:

debootstrap lenny /usr/chroot/$MACHINENAME
echo ${MACHINENAME}_chroot > /usr/chroot/$MACHINENAME/etc/debian_chroot
chroot /usr/chroot/$MACHINENAME su -

Thanks to Yuval Kogman for pointing out this great talk - Systems that Never Stop (and Erlang).

Yesterday I was watching "Google Chrome OS Open Source Project Announcement":

The "Chrome OS" got demystified, well at least for me. It's nothing more, but also nothing less than a project to throw away some conventions about current systems. Or some people say returning back to the thin client era. Basically "Chrome OS" is (will be?) a damn fast init loader. Init that will load just the things needed to run a browser. Then it is up to the browser to fulfil the consumer needs.

The challenging part will be to add all the HTML5 and other features needed to make browser have all the power of classical desktop applications. Like access to HW acceleration, offline storage, popups, etc. Another challenging part will be to convince people to write real web apps using these features.

Everyone knows make and Makefiles? At least in Perl world everyone is using it when installing ExtUtils::MakeMaker CPAN distributions. It is present on most of the systems, so why no to find it some more usage? (read save time, ease the work)

Makefile was originally created to help compiling and linking C source code. So? So the point is that we don't have just to compile source code, but we can use Makefile-s to process any kind of dependency based files chain. Inside the Makefile there is always a target file that should be generated together with dependency files needed for generation and a set of commands to perform the task. In addition targets can be made PHONY which means that the target commands will be always executed. This is most often used for "clean" target - `make clean`, which should removed all temporary build/generated files and tidy-up the folder.

The PHONY functionality can be used beyond housekeeping do define set of commands (or a library of commands) that make sense for current folder. For development project this can be `make upload`, `make deploy` or `make ajoke` or what ever comes in handy.

The Makefile of ba.pm.org has couple of targets. Transforming .po files to .js (using po2json), .xml to .tt2, .rdf or .js (using XSLT), minifying js and css (using yuicompressor), etc. There are also a couple of PHONY targets like 'all' (to build the page), 'test' (to test the xml and site linking), 'clean' + 'distclean' to tidy-up.

This MT4 installation seems to have some encoding problems. It's destroying the non-ASCII characters. I'm not suspecting the database and also not the web server, but I don't know... Let's see first some screen shots.

Writing new Entry

after clicking "Preview"(note the "You are previewing the entry titled" on top compared to the title in the preview)

after just clicking "Re-Edit this Entry" and again "Preview"

So it seems that the characters comes properly to the code and are properly written to the preview file, but then when used back again for MT4 administration interface, gets messed up.

Little more investigation and it looks like that the FastCGI is doing the double encoding. When using just CGI versions everything works just fine and I can write (šžčťľúüô) what ever I like...