Skip to main content

Ralsina.Me — Roberto Alsina's website

Rethinking Linux Configuration: Part I

Lin­ux is most­ly con­fig­ured via text files. They are ei­ther hand-edit­ed, or you use a tool that ed­its them and call it a "con­fig­u­ra­tion tool".

Of course, mod­i­fy­ing con­fig­u­ra­tion files is an er­ror-prone process which caus­es end­less grief to sys­tem ad­min­is­tra­tors. Con­sid­er the fol­low­ing fake anec­dotes and see if they ring a bel­l...

I changed some­thing and now the Frobozz does­n't click. I need to go back to the pre­vi­ous con­fig­u­ra­tion, so I used the back­up. But that al­so un­did a fix I had made to the Bar­fula­tor, so now the Bar­fula­tor is bro­ken, be­cause I don't re­mem­ber how I fixed it.

This is a prob­lem of change man­age­men­t, and the ob­vi­ous so­lu­tions are:

  1. Put /etc/ in CVS/SVN/Hg/GIT/What­ev­er. You will find a bazil­lion blog posts sug­­gest­ing this. One word: per­mis­­sion­s. As in "SVN does­n't re­mem­ber the per­mis­­sions of files, so if you check­­out /etc it is just bro­ken by de­­fault"

  2. Doc­u­­ment ev­ery­thing. Yeah, right.

I want­ed help main­tain­ing the Evil­Base sys­tem, so I gave the root pass­word to Jef­f. Then, when I was busy, deskjock­ey23 called, pushed him, and Jeff tried to help him. He made a mis­take and now all of deskjock­ey23's files in the file­serv­er have the wrong per­mis­sion­s.

This is a prob­lem of gran­u­lar­i­ty. On Unix, it's pret­ty much all or noth­ing. There are some sug­gest­ed so­lu­tions for this, too:

  1. Use a mod­­u­lar ad­min tool set and give Jeff per­mis­­sion to use on­­ly a few mod­­ules. The clas­sic ex­am­­ple is We­b­min. Then again, if there's no Evil­Base we­b­min mod­­ule, you are screwed. If you want to use vi to con­­fig Evil­Base, you are screwed, too.

  2. Don't let Jeff help you.

Now, I will pro­pose, and im­ple­men­t, a sys­tem that fix­es all these prob­lems (un­less I run in­to an un­fix­able sit­u­a­tion).

It will be a mod­u­lar ad­min tool. How­ev­er, it will let you use vi to con­fig­ure things. Or a graph­i­cal tool, if you wan­t.

It will have a sort of ver­sion con­trol sys­tem you can use to roll­back changes and have sane change man­age­men­t, but it will not be in­sane­ly an­noy­ing, and will still han­dle per­mis­sions ACLs, and ex­tend­ed at­tributes cor­rect­ly.

It will help you doc­u­ment your changes.

It will let Jeff help you.

It will not make Jeff harm­less. There are too many ways to es­cape any­thing.

Greedy, ain't I?

The First Element - Package Configuration Profiles

Let's con­sid­er what you should be able to "touch" in or­der to man­age some­thing in Lin­ux.

As you prob­a­bly know, on Lin­ux con­fig­u­ra­tion is kept in /etc. Usu­al­ly apps sprin­kle files in there and/or cre­ate a fold­er where its files live.

Ex­am­ples (con­fig files each pack­age in­stall­s):

  1. Sam­ba:

  2. Dhcpd:


So, of course, the Sam­ba ad­min should be able to touch files re­lat­ed to Sam­ba and not those re­lat­ed to Dhcpd, or oth­er things.

And here is where it gets trick­y. Should the sam­ba ad­min­is­tra­tor be able to ed­it /etc/­pam.d/sam­ba? Hell no! But he should be able to ed­it /etc/sam­ba/smb­pass­wd which is not list­ed.

So, there is a need to de­fine specif­i­cal­ly per-­sub­sys­tem, what the ad­min­is­tra­tor of that sub­sys­tem "own­s".

I wrote a naïve lit­tle script that cre­ates rather cor­rect pro­files for my own sys­tem, and should be hack­able to work on oth­er Lin­ux vari­ants. Here is what it says for the two ex­am­ples above (pack­age, fold­er 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 dan­ger­ous by re­mov­ing /etc/r­c.d/d­hcpd since that's a script that runs as root but I am not fo­cus­ing on ac­tive­ly ma­lig­nant ad­mins here.

So, con­sid­er these au­to­gen­er­at­ed pro­files as just a start­ing point to be re­fined (for ex­am­ple, there could be a list of fold­ers where no pro­file could have a file, and then you kill /etc/r­c.d, /etc/­pam.d, etc).

Here is the prof­ scrip­t:

#!/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

# 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/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:

  # 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')


  for f in flist:
    if not f:
    #In arch it gives pkgname fname and I only want fname
    fn=f.split(' ')[1]


    # I don't care about non-/etc files yet
    if not dname.startswith('/etc'):

    if dname not in IGN_DIRS and dname not in folders:

  while flag:
    for folder in folders:
      if os.path.split(folder)[0] in folders: # Redundant

  print pkgname, folders, files

It should be pos­si­ble to use the out­put of this scrip­t, af­ter some care­ful edit­ing, add ACLs, use su­do and then turn Jeff in­to a Sam­ba ad­min with­out mak­ing him more pow­er­ful than he needs to be.

But that's not nice. That's man­u­al. That on­ly solves part of the gran­u­lar­i­ty prob­lem we men­tioned above!

So, that is not what I in­tend to do. Stay tuned for Part II on fri­day No­vem­ber 30, 2007.

Juanjo / 2007-11-28 17:58:

"y convertir a Jeff en un administrador Samba" debería ser "y convertir a Pepe en un administrador Samba".

Saludos, espero la próxima entrega.

Roberto Alsina / 2007-11-28 18:42:

É vero! Corregido...

Escolos de la poliglotez.

Contents © 2000-2023 Roberto Alsina