SCIENTIFIC-LINUX-USERS Archives

December 2016

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Sat, 31 Dec 2016 16:28:04 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
I've just built a fresh new 7.2 machine. It's been an SELINUX adventure, so far. 
Here are some observations for the developers of various parts of the system. 
Mostly they are documentation and SELinux issues. Documentation would have 
helped deal with the SELinux issues. There is one serious deficiency noted below 
in subversion. (And for the standard whine, systemd sucks dead bunnies through 
garden hoses - chiefly due to nearly totally absent documentation.)

Among the problems I found is that subversion does NOT work out of the box. Its 
install does not create the repository location declared in its /etc/sysconfig 
file. Creating it "almost" makes it work. I fussed around following 
troubleshooter suggestions which all failed. Ultimately I bit the bullet and 
tried a system wide relabel. (I am not sure if I've broken dovecot yet. I think 
not.) That worked. Two things would have helped. First setting up /var/svn with 
the right contextual rules right off the bat. Second is, IMAO, a serious 
deficiency in svnserve. It apparently cannot be run as a user (subversion) 
rather than root. For the 6.x system subversion in a subversion account with 
limited permissions. It's a belt and suspenders thing. SELinux has been a severe 
PITA during this build. It's troubleshooting advice is usually useless.

On to the real reason for writing this. I have some idiosyncratic iptables rules 
I rather like. They involved "recent". I setup some open ports, notably ssh, for 
limited access. A given address can attempt a SYN packet to the machine no more 
frequently than once every 90 seconds. Imagine trying to "guess" an even "fair 
at best" password under those conditions without lighting a nuclear level flare 
in the logs.

Obviously I really do NOT want firewalld to run. This is, apparently, usually 
done using "systemctl mask firewalld". Unfortunately this leaves divots all over 
the logs about systemctl not being able to bring up /dev/null er firewalld. That 
seems "unfriendly" to say the least. (And it seems there is no "friendly" way to 
undo the "systemctl mask" command, at least for firewalld.

And I mentioned dovecot above. It as an adventure to get my usual 
fetchmail->sendmail->procmail->spamc->mbox file working. I managed to find the 
way to do this with postfix. (procmail? Um, historical - dates from before 
modern alternatives and is usefully aggressive about forcing the email through 
spamassassin.) Then I needed to setup Dovecot to suck the email back off the 
system. This was a PITA on 6.x. It is a ROYAL SELinux PITA on 7.2. Some better 
documentation would be most helpful, if anybody can be motivated to commit the 
writing effort.

{^_^}

ATOM RSS1 RSS2