--- category: '' date: 2007/11/28 13:32 description: '' link: '' priority: '' slug: BBS46 tags: programming, python, sysadmin, linux title: 'Rethinking Linux Configuration: Part I' type: text updated: 2007/11/28 13:32 url_type: '' --- Linux is mostly configured via text files. They are either hand-edited, or you use a tool that edits them and call it a "configuration tool". Of course, modifying configuration files is an error-prone process which causes endless grief to system administrators. Consider the following fake anecdotes and see if they ring a bell... I changed something and now the Frobozz doesn't click. I need to go back to the previous configuration, so I used the backup. But that also undid a fix I had made to the Barfulator, so now the Barfulator is broken, because I don't remember how I fixed it. This is a problem of change management, and the obvious solutions are: 1) Put /etc/ in CVS/SVN/Hg/GIT/Whatever. You will find a bazillion blog posts suggesting this. One word: permissions. As in "SVN doesn't remember the permissions of files, so if you checkout /etc it is just broken by default" 2) Document everything. Yeah, right. I wanted help maintaining the EvilBase system, so I gave the root password to Jeff. Then, when I was busy, deskjockey23 called, pushed him, and Jeff tried to help him. He made a mistake and now all of deskjockey23's files in the fileserver have the wrong permissions. This is a problem of granularity. On Unix, it's pretty much all or nothing. There are some suggested solutions for this, too: 1) Use a modular admin tool set and give Jeff permission to use only a few modules. The classic example is Webmin. Then again, if there's no EvilBase webmin module, you are screwed. If you want to use vi to config EvilBase, you are screwed, too. 2) Don't let Jeff help you. Now, I will propose, and implement, a system that fixes all these problems (unless I run into an unfixable situation). It *will be* a modular admin tool. However, it will let you use vi to configure things. Or a graphical tool, if you want. It *will have* a sort of version control system you can use to rollback changes and have sane change management, but it will not be insanely annoying, and will still handle permissions ACLs, and extended attributes correctly. It *will* help you document your changes. It *will* let Jeff help you. It *will not* make Jeff harmless. There are too many ways to escape anything. Greedy, ain't I? The First Element - Package Configuration Profiles -------------------------------------------------- Let's consider what you should be able to "touch" in order to manage something in Linux. As you probably know, on Linux configuration is kept in /etc. Usually apps sprinkle files in there and/or create a folder where its files live. Examples (config files each package installs): 1) Samba:: /etc/conf.d/samba /etc/logrotate.d/samba /etc/pam.d/samba /etc/rc.d/samba /etc/samba/smb.conf.default /etc/xinetd.d/swat 2) Dhcpd:: /etc/dhcpd.conf /etc/rc.d/dhcpd So, of course, the Samba admin should be able to touch files related to Samba and not those related to Dhcpd, or other things. And here is where it gets tricky. Should the samba administrator be able to edit /etc/pam.d/samba? Hell no! But he should be able to edit /etc/samba/smbpasswd which is not listed. So, there is a need to define specifically per-subsystem, what the administrator of that subsystem "owns". I wrote a naïve little script that creates rather correct profiles for my own system, and should be hackable to work on other Linux variants. Here is what it says for the two examples above (package, folder list, file list):: dhcp [] ['/etc/dhcpd.conf', '/etc/rc.d/dhcpd'] samba ['/etc/samba'] ['/etc/conf.d/samba', '/etc/logrotate.d/samba', '/etc/pam.d/samba', '/etc/rc.d/samba', '/etc/xinetd.d/swat'] Of course, you can make Jeff a bit less dangerous by removing /etc/rc.d/dhcpd since that's a script that runs as root but I am not focusing on actively malignant admins here. So, consider these autogenerated profiles as just a starting point to be refined (for example, there could be a list of folders where no profile could have a file, and then you kill /etc/rc.d, /etc/pam.d, etc). Here is the profgen.py script: .. code-block:: python #!/usr/bin/env python # A command that returns a list of the system's packages PKGL_CMD='/usr/bin/pacman -Q' # A command that lists the files in a package PKGC_CMD='/usr/bin/pacman -Ql %s' # The folder where service scripts live SRV_DIR='/etc/rc.d' # These folders should not become part of any package profiles IGN_DIRS=[SRV_DIR, '/etc', '/etc/pam.d', '/etc/xinetd.d', '/etc/profile.d', '/etc/cron.d', '/etc/cron.daily', '/etc/cron.weekly','/etc/cron.hourly','/etc/cron.monthly', '/etc/conf.d','/etc/logrotate.d', '/etc/sv'] # It gets uglier starting here;-) import os,sys from subprocess import * pkglist= Popen(PKGL_CMD.split(' '), stdout=PIPE).communicate()[0].split('\n') for pkg in pkglist: if not pkg: continue # In Arch it's # pkgname version # And I only want the pkgname pkgname=pkg.split(' ')[0] flist= Popen((PKGC_CMD%pkgname).split(' '), stdout=PIPE).communicate()[0].split('\n') folders=[] files=[] for f in flist: if not f: continue #In arch it gives pkgname fname and I only want fname fn=f.split(' ')[1] dname,fname=os.path.split(fn) # I don't care about non-/etc files yet if not dname.startswith('/etc'): continue if dname not in IGN_DIRS and dname not in folders: folders.append(dname) else: files.append(fn) flag=True while flag: flag=False for folder in folders: if os.path.split(folder)[0] in folders: # Redundant flag=True folders.remove(folder) print pkgname, folders, files It should be possible to use the output of this script, after some careful editing, add ACLs, use sudo and then turn Jeff into a Samba admin without making him more powerful than he needs to be. But that's not nice. That's *manual*. That only solves part of the granularity problem we mentioned above! So, that is **not** what I intend to do. Stay tuned for Part II on friday November 30, 2007.