Looking for old news? Jump directly to the news archive!
Did you have a look at current virtual machine management programs? Do you also feel that there's no easy-to-use, straightforward solution out there? My try to fix that problem is named creature.
It's still in it's early design phase, but digging through the README and the code can give you an impression of where it directs to.
Back from the holidays, the sysadmins are meeting in the ETH to discuss Puppet on
Wednesday, 2010-08-25, 15:00, CAB/E/79 (meeting point)
If you're interested, feel free to join us!
If you're changing networks a lot, but want to keep a some static settings, this is one way to do it.
Motivation
As most wireless networks are featured with unreliable and slow connections, I'm running my own (caching only) dns server on my notebook, to keep the answers in my local cache. Thus I always want to have
nameserver 127.0.0.1
as the first entry in my resolv.conf.
Additionally, I always want to have schottelius.org and ethz.ch in my search path, resulting in
search schottelius.org ethz.ch
Thus I am always able to type only the hostname, independent of my location.
Implementation
I am currently using dhcpcd, which is shipped with archlinux by default.
The package contains /usr/lib/dhcpcd/dhcpcd-hooks/20-resolv.conf, which takes /etc/resolv.conf.head and /etc/resolv.conf.tail into account.
According to resolv.conf(5), if multiple nameservers are specified, they will be asked in the order listed, so
echo nameserver 127.0.0.1 > /etc/resolv.conf.head
ensures that my local nameserver is asked firstly. As the domain and search field override each other, the last entry wins:
echo search schottelius.org ethz.ch > /etc/resolv.conf.tail
Further information
The same can easily be done with other modular dhcp-clients, like udhcpc (part of busybox).
The behaviour of your resolver library may be different, be sure to check your local system documentation.
There are a lot of small caching nameservers available. I have good experiences with dnscache, dnsmasq and unbound.
After a long time running websites, I decided to take some websites of mine down and to migrate the interesting parts into this website.
The unmodified versions have now a place to rest until I stop running websites: archive.schottelius.org (and also the German version archiv.schottelius.org) is the new home for my old websites.
After having setup the sysadmin console, it's now time to find out
Where to start?
Background
When I start a new job somewhere, the biggest challenge in the beginning is to find out, what to do, where, when and how. In most companies this becomes clear after a few days. In ETH, it's a bit different: There are many internal service providers, each with very different focus. To find out which are the machines I have to take care of, where they are located and which services are running on them took me about a year.
Step one: My bosses and the local sysadmins
The ones who hired me should best know, what needs to be done. After getting some basic information, the next information centre here in ETH is the ISG, the "IT Service Group", which takes care of general IT issues in the department. In my case this is the the isginf.
Your local ISG
So, what's about that ISG thingy? Why is it needed if I am hired as a sysadmin? Aren't we competing against each other? The simple answer is: No. While the ISG is also doing sysadmin related stuff, their focus is on a broader view than the one of a dedicated sysadmin. To quote from their site:
...purchasing and repairing hardware....
...operating various central services...
...administration of several hundreds of workstations...
...allow the users...to concentrate on their main tasks...
So as a sysadmin, maintaining hundreds of server and cluster machines, focussing on the groups demands, the sysadmin is mostly working in a different area. On the other hand, a sysadmin can have the ISG maintain stuff in the group, which they can do good and the sysadmin probably does not want to do (like Windows workstations).
Step two: Retrieve information from newly know sources
After the initial contact with the local folks, I'm ready to dig into other sources I am know aware of. In this case:
Systems Group in detail
Most of the information related to the sysadmin job for the Systems Group can be found in the wiki. Though the wiki is probably always a little bit behind the reality, it is heavily used and gives pointers to the right places.
/sans/: Sysadmins home
This is still a pretty young project, but unique at ETH: It is a regular sysadmin meeting and information exchange, without the formal stuff or the the borders of departements. You may find a lot of sysadmin related information directly on the website or find out more in one of the meetings.
ID: Informatikdienste
The ID are offering basic IT services for the whole ETH. Most of the network stuff and things like the Blog service is made by them. Although as a sysadmin you're mostly just using their services without interacting with the people behind them, it's a good thought to get in contact with them: In case the network is not working anymore, they are the right ones to ask for help.
There's a "little" trap though: The ID combine a lot of "smaller" departements and one has to find the right one for the right problem.
Step three: Not offering your own services
While after some time a sysadmin will find out that a particular service is missing in the group, it is probably worth not to offer it yourself: Although one may get the impression that this particular service is not available at ETH, you may almost always be wrong:
Almost every service is already being provided somewhere at ETH.
Step four: Offering your own services
After one has tried out the various services, you may still be unsatisfied: Either because the service is not being offered they way you require or it takes you a lot of time and energy to use it. While it may be worth and useful to run your own service, always triple check step three!
If you read this blog regulary, you probably know that I work as a sysadmin at the ETH Zürich.
I decided to think about all the services I provide and to document them very well, so that anybody else with some technical background could redo, what I did.
Motivation
For most jobs I've had, it was always one aim to make myself redundant, because this proves that I did a good job.
Secondly this gives me a good chance to review my infrastructure and verify that every services can be brought up again very fast and with a minimal amount of time spent from my side.
Step one: The console
Probably the most important device in a sysadmins life is the own machine. All the cool tools I've found, scripted or documentation boundled together took me years of time.
Sure, most of the stuff is also mirrored to my brain, but definitely not perfect, nor very easy to share with others.
Thus if I had to restart my job as a sysadmin, the first steps I would take, are the following:
- Get a machine (if it's a notebook, desktop, mobile phone doesn't matter)
- Setup with an OS
- Copy existing data to my home folder
- Setup company specific details
Now I would be ready to start working. But from my experiences, I would add two more things before beginning to work:
- Setting up regular backup
- Get a second, mostly identical machine
I guess the reasons for having a backup is clear for every sysadmin reading this. The reason for the second device may not be clear for everybody:
If my console dies (and hardware does that pretty often), I'm unable to work until I setup a new machine. Thus the first security to create in my job as a sysadmin, is to ensure I can work and resume working after a damage as soon as possible.
Upcoming posts
This post is the start of a small series containing all the steps needed to the current infrastructure I maintain in the Systems Group. Upcoming posts will be both tagged with eth and sysadmin.
Yet another clean and shiny puppet-module published by /sans/ that can be used by you!
This postgresql puppet module allows you to specify the version of postgresql and whether to enable or disable the service!
A new version of ceofhack has been released, which includes a clean UI interface.
It also includes a "sample UI", ui-cmd, which can be used on the command line for testing.
In theory, all new commands can be handled asynchronously, the implementation is still synchronised though.
Have fun with it and let me know, whether it works for you or not!
After a very long time I decided to give a rewrite of gpm a try.
Motivation
The recent discussion on the mailing list reminded me of one thing, since I overtook gpm maintenance:
- There are a lot of problems with gpm
Don't understand me wrong, gpm is a great software, knows how to handle a lot of mice and has many interesting programming techniques inside.
To extend gpm or to debug it, is pretty hard, as the code is not easy to read nor to understand (though fun if you do).
Some time ago I asked around in the world of BSDs, in the Linux kernel and the xorg developers, what their preferred way would be to handle mice.
As there have been almost no responses, it seems everybody does his own thing. I was also considering whether merging gpm into some "general input library" makes sense, but at the end of the day: I only care about mice.
Current situation
So yesterday evening I began to hack a new version of gpm, gpm2, which can show you some ps/2 mouse movements as of today.
The concepts of gpm2 are quite different to those of gpm, especially that gpm2 itself cannot
- decode mice protocols
- draw a pointer
Instead the idea of gpm2 is to have external programs do that and make gpm2d just an interface to access the various mice.
The "special case" of drawing a pointer can be realised by writing a gpm2 client that does only that particular job.
The future
I am not sure whether to invest a lot of work into gpm2 or not. On the one hand I would be pretty happy to have a clean, portable mouse handling daemon on the other hand I am not sure whether there is really a need for it. That said, it depends a lot on the feedback I get from others.
In case you have an opinion regarding gpm2, think there's a need for it, or totally disagree with me (or anything in between), I would like you to drop a mail to the gpm mailinglist and let me know what you think about gpm2.
And if you like them very much, you're invited to port or rewrite mouse drivers for gpm2. ;-)
All bigger projects of unix.schottelius.org have been moved to this site already. With cconf, the last "interesting" bits have been moved. I did not migrate decr-f, because it needs a major cleanup anyway.
If you are missing any software or documentation that used to be on unix.schottelius.org or linux.schottelius.org, do not hesitate to contact me.