L'uso di questo sito
autorizza anche l'uso dei cookie
necessari al suo funzionamento.
(Altre informazioni)
Showing posts with label system administration. Show all posts
Showing posts with label system administration. Show all posts

Wednesday, February 12, 2014

On turning Linux into Windows

What follows is my reply to this very good post  by Paul Selegue Eberhart.

My feelings exactly. I do not think this train can be stopped however. Not since Fedora bug 53407  and the ensuing  discussion. (TL;DR: Turned out FC12 suddenly was allowing console users install signed packages without prompting for root password. The developers responsible for the change argued endlessly that the change was for the best, and that legacy Unix mindset was preventing them from doing cool things)

It's "Because of the mouldy figs we cannot be kewl", and "We should not be afraid of complexity"  (these folks have never heard of the blob antipattern). Too bad Redmond was not hiring more coders, the problem would have been solved.

What will probably stop  this move to turn Linux into Windows is that the growing irrelevance  of the Linux Desktop will turn their sights on mobile development. Then the server people and saner attitudes will be given a chance.

(I didn't know that systemd shared authorship with pulseaudio. Now that I know, I will have to ponder a platform transition from RedHat for my servers. Although it would have to be to some *BSD* as I am not very partial to the Ubuntu vagaries, either.)

P.S: the aforementioned FC bug has this illuminating exchange:

> > This is really a *major* change that is precise opposite of the way *NIX has
> > always worked.  
> 
> I don't particularly care how UNIX has always worked.

I do, or I'd be using Windows.

Friday, April 12, 2013

The strange world of SELinux and webmin

I am willing to share a few more sysdamin pains today, for the BDSM oriented people who enjoy suffering.

I am testing webmin on a CentOS 6.3 machine today. Purpose: creating a restricted web-paneled environmente where a basically skilled admin can add users, mailboxes, aliases and so on  without hosing the system or opening mile-wide holes into it. It does look doable so far except....

I want mail delivery done in Maildir-style folders under the user homedir. Procmail is the perfect tool for this, given the following /etc/procmailrc:


LOGFILE=/var/log/proc_log
DEFAULT=$HOME/mail/


(Hint: the trainling slash does the trick).

Enters webmin, breakage begins.  A webmin-added user, balf, cannot have mail properly delivered, while a adduser-added user alf, can. Ostensible reason being that, in the first instance, procmail is incapable of creating the mail/ directory. The logfile trace is self-explanatory as usual:


procmail: Unable to treat as directory "/home/balf/mail"
procmail: Locking "/home/balf/mail.lock"
procmail: Error while writing to "/home/balf/_D3D.N35ZRB.localhost.localdo"
procmail: Lock failure on "/home/balf/mail.lock"
procmail: Assigning "LASTFOLDER=/home/balf/mail/"
procmail: Opening "/home/balf/mail/"
procmail: Error while writing to "/home/balf/mail"
procmail: Assigning "LASTFOLDER=/var/spool/mail/balf"
procmail: Opening "/var/spool/mail/balf"
procmail: Acquiring kernel-lock


Uh?

Google brings no joy other than the usual check permissions and stuff. Which I did. The gut instinct reaction (manually creating the mail directory) just pushes the problem deeper. Some work succeds in making the users exactly the same (same permissions, on home dirs, same group, same passwd and shadow entries, same files in the home dir. So it must be something with permissions, which means....SELinux. Which I usually turn off - but forgot on this time. 'ls -Z' verifies that the homedirs of the users have indeed different context:

 # ls -Z drwx------. alf mailusers unconfined_u:object_r:user_home_dir_t:s0 alf drwx------. balf mailusers unconfined_u:object_r:home_root_t:s0 balf

So, at this point you turn off SELinux, and all is well (put SELINUX=disabled in /etc/sysconfig/selinux).