Slashdot Mirror
Google Gets Slack with Software Updates
An anonymous reader writes "While Google's open source project titled 'Slack' was released over a year ago, last week's Australian Unix Users Group Conference marks the first time that Google has ever discussed the system in public. Corporate systems administrator Michael Still helped to illuminate a little bit about how Google uses Slack and how their network of computers fits together. From the article: '"Slack is a source deployment system and it's the way we install applications on servers," Still said, adding Slack is based around a centralized configuration repository which is then deployed onto selected machines in a "pull" method. Each of the "worker" machines asks for its new configuration regularly or when a manual command is run.'"
How closely is Google Slack, tied to Slackware? If it's not, why did they choose that name? The Slashdot icon and URL suggests this story has to do with Linux.
Oh You POS
Before anybody says "Hey! Where's the source?!", let me just provide a link right now:
http://www.sundell.net/~alan/projects/slack/
Do me a favor and don't destroy sundell's server, or he's likely to hurt me :-P
I doubt it will get too slashdotted, but just in case, this is the link with the downloads coming from coral cache:
/~alan/projects/slack
:)
Index of
[TXT] COPYING 13-Oct-2006 00:09 1k
[TXT] ChangeLog 13-Oct-2006 00:09 7k
[ ] slack-0.13.1.tar.gz 08-Jan-2005 20:01 28k
[ ] slack-0.13.2.tar.gz 09-Feb-2005 11:27 28k
[ ] slack-0.14.0.tar.gz 13-Oct-2006 00:09 47k
Short Description:
slack is a configuration management system designed to appeal to lazy
admins (like me). It's an evolution from the usual "put files in some
central directory" that is faily common practice. It's descended from an
earlier system I also wrote, called "subsets", and uses a multi-stage
rsync to fix some of the problems I had there.
Basically, it's a glorified wrapper around rsync.
License:
See the file COPYING.
Getting slack:
http://www.sundell.net/~alan/projects/slack/
Documentation:
Not much, but there's some in doc/
Reporting problems:
Send an email to <sundell (at gmail.com)>. Probably want to put
"slack" in the subject and be patient for replies.
$Id: README,v 1.5 2006/09/25 21:35:22 alan Exp $
FWIW, the name is an acronym: SLACK - Sysadmins' Lazy Auto-Configuration Kit
What they're describing there is like Debian's apt-get, or BSD's portage (also incorporated in Gentoo). Each of those technologies I listed are most commonly used to install packages from a common central repository over the internet (per distro). But, each of them can be configured to retrieve and install packages from a localized server. It's actually a very handy thing to have in large-scale networks because instead of installing and updating packages on each machine over the internet from a remote repository, you just update one machine from the internet and let all the rest of them update from it, thus cutting way back in internet usage and greatly reducing the time needed for the local machines to download and install updates.
Sounds like Slack is a simplified version of all of that.
/* No Comment */
You mean OpenLDAP, Samba, Kerberos, Bind.
I can give you one better.
I use Mandriva Linux as my Domain Controllers and workstations.
With urpmi's parallel operation with SSH support is a Godsend. See my Secure Shell server is GSSAPI enabled (Kerberos.) Because of the fact every machine is authorized by LDAP, and authenticated by Kerberos, I can do this:
urpmi samba-server --auto --parallel dcs
This will install Samba on all Domain Controllers
urpmi gnumeric --auto --parallel all
This will install gnumeric on every machine in my Domain.
urpmi.update -a
urpmi --auto --auto-select --parallel all
This will update every machine I have in my Domain while resolving dependancies. There are problems with doing it this way. The big one is, under AD, updates can be pushed to offline machines. For this to work, all machiess must be online.
Also this does not update the urpmi catalogue synthesis.
Gentoo is not Ports. Ports is not Gentoo. Gentoo is inspired by BSD's ports, which is why the Gentoo package manager is named portage. But there are huge differences.
Last I checked, Ports was primarily a distribution system. Portage is a full-fledged package manager that happens to use source packages, and happens to have a file called "make.conf".
True, and they mention this. Gentoo's probably the closest, but their main motivation for rolling their own is to be able to go into a filesystem and tweak it, instead of having to tweak, build an RPM (or Deb, or whatever), download that to the target machine, etc etc.
It's also simultaneously a like cfengine, which is used to manage configurations. That is, it's not just for packages, but also for app configurations. That is, if your webserver goes down, hard, you can bring a new one up in an hour, 100% automated, and it will be configured the exact same way as the old one. If you need to add a new webserver to the cluster, same process. Want to change the config on a webserver? Test it on a local machine, then put the new httpd.conf on the Slack server, and watch all the frontend machines download it.
Personally, I think they should've at least looked into cfengine, but APT alone is not enough. Saying APT could do it is like saying you can write a webserver in assembly -- yes, you can, but why would you want to?
Don't thank God, thank a doctor!
You (and most others here) are largely missing the point. Slack is not a replacement for apt or rpm. It's more comparable to something like cfengine, although it's only vaguely in the same universe because Slack is so much simpler. Here's what goes in a slack role:
That's it. You don't tar it up, you don't make a package, you don't have to learn a special language to describe your changes, etc. Nothing fancy. I know those four items sound similar to what you can do with a package management system, and they are, but that's not what this is for. You don't put binaries (for example) in a Slack role - slack is for higher-level stuff like your customized config files. You *could* roll custom packages for your config files and whatnot, but that's a lot of work (relatively speaking).
Say I've got a slack role for my web server. In the preinstall script, I'd make sure the right packages are installed, so I'd do something like "apt-get install apache2". Then in the files section, I'd have etc/apache2/httpd.conf along with whatever other config files I use for my installation. In the postinstall script I could check to see if I've just installed new config files and restart apache if I have.
That's all there is to it - it's purposely extremely simple, to make it easier than just copying files from an existing server to a new one when you set one up. Laziness usually wins out (a law of human nature, not a statement about google sysadmins :-P), so if config management is too much work, it either has to be forced upon everybody or it won't be used. Additionally, since you don't do anything with the files and scripts you put in a slack role, you can trivially put your slack repository in Subversion or CVS or your revision control du jour, so getting people to use Slack has the nice side effect of also getting them to use revision control for their config files!
And yes, I use it on my personal server with two admins :-P