Re: Adventures with 7.2

[jdow]

On 2017-01-09 16:04, Konstantin Olchanski wrote:

On Sat, Jan 07, 2017 at 08:18:38PM -0800, jdow wrote:


Blanket disabling both of [selinux and iptables] at once, permanently is stupid 
beyond
belief ...




And then there is the reality:

In el6 (and earlier), selinux was not functional and iptables were not enabled 
by default.

So I see el7 is a big improvement:

a) iptables/firewalld is enabled by default and is easy to manage. no reason to 
turn it off ever.
b) selinux is mostly functional except for obscure bugs.

So we go from 0-out-of-2 to 2-out-of-2, unless you have been burned and scarred
(but not fired) by the NFS server bug, that it is 1-out-of-2.


SELinux worked for me for quite awhile on 6.2 on up. Now, with 7 (and perhaps 
with 6) there are some problems I don't know enough to work around. I have a 
MESSY workaround in 6.x. I learned of what the files in /etc/dhcp/dhclient.d do. 
So I used that to update a manually generated iptables that has a trick on open 
ports that allow one login per 90 seconds (or whatever I set it to). That 
worked. A file named "iptables.sh" calls the real iptables script I have tucked 
away in /etc/sysconfig.


Now, all that works; but I have an email arrangement that uses "fetchmail" to 
pull mail down from my ISP. I've found in the past it seems to have problems 
when the IP address from the ISP changes. (Damnifinowhy) And I have to get it 
started in the first place. "RestartMail.sh" seemed like the perfectly logical 
place to make sure it starts.


RestartMail.sh at first tried to "sudo" to the appropriate account and run a 
start mail script there. Nope. Fetchmail could not save or manipulate it's pid 
file. Besides sudo would not reliably run. I tried "su -l user command". Nope. I 
seems to vary with the phase of the Moon or something whether su or sudo is even 
accepted in the script. And always "fetchmail -d 120" has trouble with its pid 
file. The semodules "trick" doesn't seem to work or stick around through reboots.


So, I have to fark around with crontab and a script that detects changed 
conditions so that fetchmail gets started properly.


Some REALLY good documentation for SELinux with some good drawings as well as a 
snow job of words would be worthwhile. I'm not holding my breath. I'm just 
working around the various SELinux imposed annoyances. I feel naked without it; 
but, it wears like a wool bikini - itchy and scratchy.


{o.o}

Re: Adventures with 7.2

[Konstantin Olchanski]

On Sat, Jan 07, 2017 at 08:18:38PM -0800, jdow wrote:
> 
> Blanket disabling both of [selinux and iptables] at once, permanently is 
> stupid beyond
> belief ...
>


And then there is the reality:

In el6 (and earlier), selinux was not functional and iptables were not enabled 
by default.

So I see el7 is a big improvement:

a) iptables/firewalld is enabled by default and is easy to manage. no reason to 
turn it off ever.
b) selinux is mostly functional except for obscure bugs.

So we go from 0-out-of-2 to 2-out-of-2, unless you have been burned and scarred
(but not fired) by the NFS server bug, that it is 1-out-of-2.


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: Adventures with 7.2

[Konstantin Olchanski]

On Sun, Jan 08, 2017 at 04:30:06AM +0100, David Sommerseth wrote:
> On 06/01/17 23:56, Konstantin Olchanski wrote:
> > On Sat, Dec 31, 2016 at 04:28:04PM -0800, jdow wrote:
> >> ... new 7.2 machine.
> >> ... SELinux issues.
> >>
> > You *must* disable SELinux in CentOS-7.
> 
> *That* deserves the price for the worst advice in 2017.
>


David, you are ignoring the specific reasons why I say this.

a) "reboot with selinux disabled" has been the only way to delete
files from ZFS. May be fixed in the latest release of ZFS.

b) for the NFS server, you can run with SElinux as long as you manually
specifying unique "fsid" values in /etc/exports. This work around
is not widely known, not included in the documentation.

If these two bugs inspire confidence in selinux, sure, leave it enabled. A good 
example
of "medicine is as bad as the disease".

Personally, I am amazed that Red Hat, a server OS vendor, would have a 
continuing
bug where the NFS server is broken if SElinux is enabled. Today's quality 
standard
seems to be "but it works just fine on my laptop!".

P.S. For reference,

the NFS server bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1350927
https://bugzilla.redhat.com/show_bug.cgi?id=1326406
(originally reported last April, still not fixed)

the ZFS bug:
https://github.com/zfsonlinux/zfs/issues/4845
(it is reported as fixed in current release of ZFS,
I do not confirm yet due to lack of time, have bigger fish to fry
than debugging ZFS and SElinux).


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: Adventures with 7.2

[jdow]

On 2017-01-09 06:04, David Sommerseth wrote:

On 08/01/17 05:18, jdow wrote:

And in a fairly clean (no servers) install iptables opened wide for
brief periods can be considered "safe enough".


Absolutely right!  Of course you should do a security assessment before
doing it, just to have an idea of the worst possible outcome and
consider if the risk is worth it or not.  But in many cases, this might
be very sensible to do.


When I can I cheat this test. The new server machine initially sits behind the 
existing firewall. {^_-}


With that in mind, I have an interesting mystery here. If I am running a 
nameserver open to the local network (but firewalled off and configured to only 
accept local queries) on a machine at say 192.168.159.3 and place that as the 
nameserver into resolv.conf it does not work. But if I tell resolv.conf to use 
127.0.0.1 it works. At the same time it fails to work for the local machine a 
laptop connected to it on the local net getting an appropriate address, say 
192.168.159.123, can use the name server.


Now, the obvious thing to do is use "nameserver localhost". But, to ease my mind 
I'd REALLY like to know why "dig" behaves dramatically differently with 
resolv.conf pointing to 192.168.159.3 when I use "dig www.foobar.com" (fails) or 
"dig @192.168.159.3 www.foobar.com" (succeeds). This is a headscratcher for me. 
Um, of course "dig @localhost www.foobar.com" also works in all cases.



Now, if you have a
telnetd running (but --- why would you do something so stupid?) opening
the firewall is suicidal.


Yes.  But there might also be misconfigured inetd/xinetd services, http
servers providing information which should be restricted, databases,
various management interfaces, etc, etc.  Hence the security assessment
is a practical exercise before doing such a stunt.


Now you've touched on a singular benefit of the "old tried and true ways". (Hey, 
I had no internet at all when I was young. I had to resort to ham radio for my 
techie fixes. BBS systems came in my 30s. So I have a right to be a fossil. 
{^_-}) A quick look at "/etc/rc.d/rc5.d" very quickly showed you what was usable 
and what was not. Then another look into /etc/xinetd.d perhaps opening a few 
files completed the survey. With systemctl the search is not quite so obvious or 
easy to read. With the old way a K in front means it's not running and an S in 
front means it is. A 5 second sweep covers the biggest set of possible holes 
before you open iptables wide.



Running 'ss -lntup' gives you a pretty good idea what the consequences
might be.  Of course if the box is routing traffic to other subnets,
that may also increase the risk.


Nice, but it's not a quick parse with a (sigh) traditional 80 character wide 
terminal window. (Yes, 132 is the other traditional width. It's er annoying to 
use as it eats screen real estate too er broadly.)



Blanket disabling both of them at once, permanently is stupid beyond
belief, IMAO.


Yes!


Some people seem to be inherently suicidal. {^_-}


OTOH the people who got in so easily might figure it's a
honeypot or something and walk away. But that's a stretch.


You're probably right, especially if the purpose of an attack was to get
insight.  If it was a drive-by-bot just wanting to install a spam-bot,
crawler or similar slave node, such details can just as well be ignored
on a target system.


Isn't it a civic duty to participate in huge DDoS attacks on "The Man?"

{O,o}   Yes, Joanne is feeling a little punchy this "morning". (Just got up.)

Re: Adventures with 7.2

[David Sommerseth]

On 08/01/17 05:18, jdow wrote:
> On 2017-01-07 19:30, David Sommerseth wrote:
>> On 06/01/17 23:56, Konstantin Olchanski wrote:
>>> On Sat, Dec 31, 2016 at 04:28:04PM -0800, jdow wrote:
 ... new 7.2 machine.
 ... SELinux issues.

>>> You *must* disable SELinux in CentOS-7.
>>
>> *That* deserves the price for the worst advice in 2017.  With '*must*',
>> that is just a way too strong advice which I hope nobody really
>> considers strongly.  It's as equally bad as saying "disable and flush
>> iptables because it blocks connections to your host".
>>
>> I honestly hoped we had moved much further forward than this ...
> 
> I have turned SELinux permissive to try to track down problems. It
> removes one giant unknown variable from the picture. I seldom leave it
> that way very long.

Which is the proper way to do it!

> And in a fairly clean (no servers) install iptables opened wide for
> brief periods can be considered "safe enough". 

Absolutely right!  Of course you should do a security assessment before
doing it, just to have an idea of the worst possible outcome and
consider if the risk is worth it or not.  But in many cases, this might
be very sensible to do.

> Now, if you have a
> telnetd running (but --- why would you do something so stupid?) opening
> the firewall is suicidal.

Yes.  But there might also be misconfigured inetd/xinetd services, http
servers providing information which should be restricted, databases,
various management interfaces, etc, etc.  Hence the security assessment
is a practical exercise before doing such a stunt.

Running 'ss -lntup' gives you a pretty good idea what the consequences
might be.  Of course if the box is routing traffic to other subnets,
that may also increase the risk.

> Blanket disabling both of them at once, permanently is stupid beyond
> belief, IMAO.

Yes!

> OTOH the people who got in so easily might figure it's a
> honeypot or something and walk away. But that's a stretch.

You're probably right, especially if the purpose of an attack was to get
insight.  If it was a drive-by-bot just wanting to install a spam-bot,
crawler or similar slave node, such details can just as well be ignored
on a target system.


-- 
kind regards,

David Sommerseth

Re: Adventures with 7.2

[Lamar Owen]

On 01/06/2017 05:46 PM, Konstantin Olchanski wrote:

People who tinker with these systems are not old school unix sysadmin
heavyweights, there is no patience (no time) to learn complicated
things like systemd or firewalld, no matter how well documented they are,
if complexity stands between me and my tinkering, out it will go,
let's see how quickly.

Well, to a rank newbie to these sorts of things, systemd and firewalld 
are no more complicated than upstart with manual iptables rules or 
SysVInit with ipchains rules (true SysVInit, not the upstart emulation 
found in EL6).  Really; to the beginner systemd is not any more 
complicated than the morass of rc files in /etc/init.d and friends.



--
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
828-862-5554
www.pari.edu

Re: Adventures with 7.2

[jdow]

On 2017-01-07 19:30, David Sommerseth wrote:

On 06/01/17 23:56, Konstantin Olchanski wrote:

On Sat, Dec 31, 2016 at 04:28:04PM -0800, jdow wrote:

... new 7.2 machine.
... SELinux issues.


You *must* disable SELinux in CentOS-7.


*That* deserves the price for the worst advice in 2017.  With '*must*',
that is just a way too strong advice which I hope nobody really
considers strongly.  It's as equally bad as saying "disable and flush
iptables because it blocks connections to your host".

I honestly hoped we had moved much further forward than this ...


I have turned SELinux permissive to try to track down problems. It removes one 
giant unknown variable from the picture. I seldom leave it that way very long.


And in a fairly clean (no servers) install iptables opened wide for brief 
periods can be considered "safe enough". Now, if you have a telnetd running (but 
--- why would you do something so stupid?) opening the firewall is suicidal.


Blanket disabling both of them at once, permanently is stupid beyond belief, 
IMAO. OTOH the people who got in so easily might figure it's a honeypot or 
something and walk away. But that's a stretch.


{^_-}

Re: Adventures with 7.2

[David Sommerseth]

On 06/01/17 23:56, Konstantin Olchanski wrote:
> On Sat, Dec 31, 2016 at 04:28:04PM -0800, jdow wrote:
>> ... new 7.2 machine.
>> ... SELinux issues.
>>
> You *must* disable SELinux in CentOS-7.

*That* deserves the price for the worst advice in 2017.  With '*must*',
that is just a way too strong advice which I hope nobody really
considers strongly.  It's as equally bad as saying "disable and flush
iptables because it blocks connections to your host".

I honestly hoped we had moved much further forward than this ...


-- 
kind regards,

David Sommerseth

Re: Adventures with 7.2

[Konstantin Olchanski]

On Sat, Dec 31, 2016 at 04:28:04PM -0800, jdow wrote:
>
> ... new 7.2 machine.
> ... SELinux issues.
>

You *must* disable SELinux in CentOS-7.

Here is the two most fun bugs that bit me so far:

a) ZFS will not free disk space when you delete files (maybe fixed in latest 
ZFS release)
b) NFS will give out random fsid handles, problem shows up when you "yum update 
systemd" on the server,
   this somehow restarts NFS, then all NFS clients go into "stale file handle" 
state. (not fixed until el7.4+)

Before el7, if I left SELinux enabled it will always eventually "eat itself" - 
the computer
will stop working because some file label somewhere will be off. With el7, 
SELinux seems
to be stable, and if you do not mind defective ZFS and NFS (and what other 
breakage),
there seem to be no harm in leaving it enabled.


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: Adventures with 7.2

[Konstantin Olchanski]

On Mon, Jan 02, 2017 at 04:00:00AM -0500, Nico Kadel-Garcia wrote:
> On Sun, Jan 1, 2017 at 5:19 PM, David Sommerseth
> >
> > ... systemd is far better documented than any other init system
> > I've used over the last 15+ years or so.
>
> daemontools was much lighter, much cleaner, and well documented. It
> never took off due to ...
>


I am amused to see how systemd-based CentOS-7 seems to run ok on
RaspberryPi-type of machines (single core 1GHz CPU, 0.5GB RAM,
10Mbytes/sec "disk", Pentium3 back to the future).

I think we will see a return of daemontools or something equally (or more)
light weight, and not only to save on memory, cpu and i/o footprint.

People who tinker with these systems are not old school unix sysadmin
heavyweights, there is no patience (no time) to learn complicated
things like systemd or firewalld, no matter how well documented they are,
if complexity stands between me and my tinkering, out it will go,
let's see how quickly.


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: Adventures with 7.2

[jdow]

On 2017-01-04 09:01, David Sommerseth wrote:

On 04/01/17 05:54, jdow wrote:



Off the top of my head, dnsdomainname, domainname, nisdomainname,
ypdomainname are symlinks to hostname; halt, poweroff, reboot,
shutdown are symlinks to systemctl; view is a symlink to vi; etc.


I hadn't dug that far. But, again, it makes sense in a weird sort of
way. It is really an ultimate reuse of code, right? {^_-}


In essence, yes.  IMO,there is often a misconception of the Unix
philosophy.  There is a good thought behind "a single program does a
single task, and does it well".  But that does not mean that each single
program must be a standalone binary, built from a standalone source code.


Besides, "one thing" is about as vague as the politicians' offers of "hope" or 
"change". Each one is modulo the speaker's definition of whatever is being 
discussed. If it is "add an iptables entry" then you "need" multiple files. If 
it means "manages iptables well" then you are encouraged to use one file. But, 
in the dark corners I inhabited decades ago that meant "ls" was neither a bunch 
of files, one for each way ls can be used, nor a single file whose behavior is 
based on input parameter 0. It meant we had "-" options. That feels more 
"wholesome", if you can catch my drift. If you go looking for "ls", for whatever 
reason - binary patch maybe, it is right there staring you in the face. With 
"foobar" that behaves differently when you call it "foo", "bar", or "baz" 
looking for the command "bar" could become tedious. But, then, why should one go 
looking for it? Erm, why should anybody ever need more than 64k? (About where 
computers started becoming human usable. Let's hear it for the HP2100S, my real 
birth machine. We shall ignore the IBM 7090 from my college days, PLEASE.)


There might be a parable in the above. Clarity at the expense of efficiency is 
bad. Efficiency at the expense of Clarity is bad. Finding a good compromise is 
best. And even that's not easy.


{^_^}

Re: Adventures with 7.2

[David Sommerseth]

On 04/01/17 05:54, jdow wrote:
>>
>>
>> Off the top of my head, dnsdomainname, domainname, nisdomainname,
>> ypdomainname are symlinks to hostname; halt, poweroff, reboot,
>> shutdown are symlinks to systemctl; view is a symlink to vi; etc.
> 
> I hadn't dug that far. But, again, it makes sense in a weird sort of
> way. It is really an ultimate reuse of code, right? {^_-}

In essence, yes.  IMO,there is often a misconception of the Unix
philosophy.  There is a good thought behind "a single program does a
single task, and does it well".  But that does not mean that each single
program must be a standalone binary, built from a standalone source code.

>From a coding perspective, code re-use is absolutely something to strive
for.  If there is an issue in the shared code, you fix the bug once and
not across X various source files or standalone projects.

And there is no real reasons why not to have a shared code base for all
the code which is basically identical.

Of course you can compile a project with, say 20 functions which results
in 20 different binary files based on shared source code.  But that is
also inefficient as well.  Each of these binary files carry an overhead
of ELF information and so on.  On most harddrives today there is less to
worry about in regards to bytes spent, but if you are in the embedded
world where each byte spent matters - this gives another advantage.

Combining all these 20 functions into a single binary reduces that
overhead.  But in addition, the file system cache can cache a single
binary while providing 20 functions out of this single cache hit ...
which results in improved performance, especially if many of these
functions are used often.

But again, that these 20 functions comes from a shared binary and from a
shared source code does not imply that each of these functions does more
than one thing and that it doesn't do it well.


-- 
kind regards,

David Sommerseth

Re: Adventures with 7.2

[jdow]

On 2017-01-03 14:31, Tom H wrote:

On Tue, Jan 3, 2017 at 3:11 PM, jdow  wrote:

On 2017-01-03 09:56, David Sommerseth wrote:


Remember that firewalld provides an API over D-Bus for dynamic
firewall updates, so this is kind of to "seal" the configuration
without breaking any component depending on manipulating the firewall
as the system is running. NetworkManager and libvirt are two
components which adjusts the firewall on-the-fly, depending on which
network you're connected to or which VMs have been started, and so on.


That still leaves me mumbling and led me down a midget rabbit hole.
The "iptables" command is 777 root root system_u:object_r:bin_t:s0;
but, that's OK. It's a link - to xtables-multi, which is rwxr-xr-x.
root root system_u:object_r:iptables_exec_t:s0. Waitaminit says I to
meself. (or is it me to iself? Whatever) Let's give that a try The
results are reassuring:
===8<---
[jdow@whereever ~]$ xtables-multi iptables -L -v
iptables v1.4.21: can't initialize iptables table `filter': Permission
denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.
===8<---
I guess the ancient philosophy of one task one command is passe' and
now a monstrosity like xtables-multi finds itself masquerading as
iptables and about a dozen other things.


/usr/sbin/iptables-restore
/usr/sbin/iptables-save
/usr/sbin/iptables
/usr/sbin/ip6tables-restore
/usr/sbin/ip6tables-save
/usr/sbin/ip6tables


Notice the command I issued. I started, of course, with something like 
xtables-multi -L -v as a first approximation. It coughed up a list of some 14 
different things it can be called as. That was not reassuring since I called it 
as a user rather than root. Then I tried the command listed. If failed but the 
message was informative enough. I, of course, escalated to prepending "sudo " to 
the command, giving my password as usual, and admired the results.



are symlinks to "/usr/sbin/xtables-multi" because it's a multi-call
binary, like busybox.


I was simply bemused that the old UNIX philosophy of one small task one command 
with results chained into the next command ad nauseum has finally been 
discovered to be silly and furthermore good sense is catching on past busybox. 
(I have the same attitude about "goto". (And despite dogma even at UniSys many 
see Dijkstra's pontification on the subject as flawed er and harmful. I live 
with one such.) {^_-}



There are others.

Off the top of my head, dnsdomainname, domainname, nisdomainname,
ypdomainname are symlinks to hostname; halt, poweroff, reboot,
shutdown are symlinks to systemctl; view is a symlink to vi; etc.


I hadn't dug that far. But, again, it makes sense in a weird sort of way. It is 
really an ultimate reuse of code, right? {^_-}



It's normal for "iptables" to fail if you call it as jdow; but if you
have polkit installed, "pkexec iptables" might work (depending on your
polkit policies; "sudo ..." and "su -c ..." will work if you're
authorized).


But of course. I've been using sudo for a very long time. (I don't remember if I 
did it with the real SVR4 machine I had. But certainly I've been using it from 
the first RH 5 or so - not RHEL or Fedora, Hurricane if my memory works tonight.


If sudo didn't work I'd have made a scene about it, probably.

{^_^}

Re: Adventures with 7.2

[Tom H]

On Tue, Jan 3, 2017 at 3:11 PM, jdow  wrote:
> On 2017-01-03 09:56, David Sommerseth wrote:
>>
>> Remember that firewalld provides an API over D-Bus for dynamic
>> firewall updates, so this is kind of to "seal" the configuration
>> without breaking any component depending on manipulating the firewall
>> as the system is running. NetworkManager and libvirt are two
>> components which adjusts the firewall on-the-fly, depending on which
>> network you're connected to or which VMs have been started, and so on.
>
> That still leaves me mumbling and led me down a midget rabbit hole.
> The "iptables" command is 777 root root system_u:object_r:bin_t:s0;
> but, that's OK. It's a link - to xtables-multi, which is rwxr-xr-x.
> root root system_u:object_r:iptables_exec_t:s0. Waitaminit says I to
> meself. (or is it me to iself? Whatever) Let's give that a try The
> results are reassuring:
> ===8<---
> [jdow@whereever ~]$ xtables-multi iptables -L -v
> iptables v1.4.21: can't initialize iptables table `filter': Permission
> denied (you must be root)
> Perhaps iptables or your kernel needs to be upgraded.
> ===8<---
> I guess the ancient philosophy of one task one command is passe' and
> now a monstrosity like xtables-multi finds itself masquerading as
> iptables and about a dozen other things.

/usr/sbin/iptables-restore
/usr/sbin/iptables-save
/usr/sbin/iptables
/usr/sbin/ip6tables-restore
/usr/sbin/ip6tables-save
/usr/sbin/ip6tables

are symlinks to "/usr/sbin/xtables-multi" because it's a multi-call
binary, like busybox.

There are others.

Off the top of my head, dnsdomainname, domainname, nisdomainname,
ypdomainname are symlinks to hostname; halt, poweroff, reboot,
shutdown are symlinks to systemctl; view is a symlink to vi; etc.

It's normal for "iptables" to fail if you call it as jdow; but if you
have polkit installed, "pkexec iptables" might work (depending on your
polkit policies; "sudo ..." and "su -c ..." will work if you're
authorized).

Re: Adventures with 7.2

[jdow]

On 2017-01-03 09:56, David Sommerseth wrote:

On 03/01/17 05:59, jdow wrote:

...

The lockdown-whitelist thing is more or less a "but why?" component.


lockdown in firewalld jargon is more like "which component/user may
modify the firewall if the firewall configuration have been locked down".

When firewalld is set into locked-down mode, no-one is able to
manipulate the firewall.  Otherwise, anyone granted admin privileges (as
defined in the PolicyKit policy for the firewalld component) may
manipulate the firewall.  So it tightens the access, regardless if
PolicyKit grants access.  The default policy have uid=0,
firewall-config, NetworkManager and libvirtd in this whitelist.

Remember that firewalld provides an API over D-Bus for dynamic firewall
updates, so this is kind of to "seal" the configuration without breaking
any component depending on manipulating the firewall as the system is
running.  NetworkManager and libvirt are two components which adjusts
the firewall on-the-fly, depending on which network you're connected to
or which VMs have been started, and so on.


That still leaves me mumbling and led me down a midget rabbit hole. The 
"iptables" command is 777 root root system_u:object_r:bin_t:s0; but, that's OK. 
It's a link - to xtables-multi, which is rwxr-xr-x. root root 
system_u:object_r:iptables_exec_t:s0. Waitaminit says I to meself. (or is it me 
to iself? Whatever) Let's give that a try The results are reassuring:

===8<---
[jdow@whereever ~]$ xtables-multi iptables -L -v
iptables v1.4.21: can't initialize iptables table `filter': Permission denied 
(you must be root)

Perhaps iptables or your kernel needs to be upgraded.
===8<---
I guess the ancient philosophy of one task one command is passe' and now a 
monstrosity like xtables-multi finds itself masquerading as iptables and about a 
dozen other things. I have a skew sense of humor so I find that amusing. I see 
it's been that way for some years now even in 6.x. I just never had cause to 
look for this. Somebody liked the inetd model later called xinetd. (Speaking of 
which, I notice systemd seems to have subsumed even that functionality. It's 
good from a central management standpoint. It's yet another unclear puzzle when 
initially trying to wrap one's mind around systemd.)


Preserving the lockdown file for something that is removed from the system, 
though, seems to be silly to my fevered brain.


Gee, my rant has led to some good learning and a slightly fascinating rabbit 
hole, as well as the frustrating systemd mile deep rabbit hole.


{^_^}

Re: Adventures with 7.2

[David Sommerseth]

On 03/01/17 05:59, jdow wrote:
> On 2017-01-02 18:40, Tom H wrote:
>> On Mon, Jan 2, 2017 at 5:06 PM, jdow  wrote:
> ...
>>>   Erasing: firewalld-0.4.3.2-8.el7.noarch
>>> 7/7
>>> warning: /etc/firewalld/lockdown-whitelist.xml saved as
>>> /etc/firewalld/lockdown-whitelist.xml.rpmsave
>>>
>>> That smells amusing and puzzling but not dangerous to me.
>>
>> So it's not fully or properly installed, :) and :(
> 
> ...
> 
> One wonders about the missing EULA info.
> 
> The lockdown-whitelist thing is more or less a "but why?" component.

lockdown in firewalld jargon is more like "which component/user may
modify the firewall if the firewall configuration have been locked down".

When firewalld is set into locked-down mode, no-one is able to
manipulate the firewall.  Otherwise, anyone granted admin privileges (as
defined in the PolicyKit policy for the firewalld component) may
manipulate the firewall.  So it tightens the access, regardless if
PolicyKit grants access.  The default policy have uid=0,
firewall-config, NetworkManager and libvirtd in this whitelist.

Remember that firewalld provides an API over D-Bus for dynamic firewall
updates, so this is kind of to "seal" the configuration without breaking
any component depending on manipulating the firewall as the system is
running.  NetworkManager and libvirt are two components which adjusts
the firewall on-the-fly, depending on which network you're connected to
or which VMs have been started, and so on.


-- 
kind regards,

David Sommerseth

Re: Adventures with 7.2

[jdow]

On 2017-01-02 18:40, Tom H wrote:

On Mon, Jan 2, 2017 at 5:06 PM, jdow  wrote:

...

/usr/lib/python2.7/site-packages/initial_setup/tui/spokes/eula.py: remove
failed: No such file or directory
  Erasing: anaconda-core-21.48.22.56-1.sl7.1.x86_64
4/7
  Erasing: anaconda-tui-21.48.22.56-1.sl7.1.x86_64
5/7
  Erasing: firewall-config-0.4.3.2-8.el7.noarch
6/7
  Erasing: firewalld-0.4.3.2-8.el7.noarch
7/7
warning: /etc/firewalld/lockdown-whitelist.xml saved as
/etc/firewalld/lockdown-whitelist.xml.rpmsave

That smells amusing and puzzling but not dangerous to me.


So it's not fully or properly installed, :) and :(


...

One wonders about the missing EULA info.

The lockdown-whitelist thing is more or less a "but why?" component.

{^_-}

Re: Adventures with 7.2

[jdow]

On 2017-01-02 18:37, Tom H wrote:

On Mon, Jan 2, 2017 at 4:58 PM, jdow  wrote:

On 2017-01-02 07:26, Tom H wrote:

On Mon, Jan 2, 2017 at 4:12 AM, jdow  wrote:


The SYS5 stuff in 6.x and prior lacked flexibility, to be sure. It was
simple enough that figuring out what was going on became easy. And
where the documentation failed the workarounds were not all that
difficult. But, then,the first 'ix I played with was one of the first
commercial renditions of SVR4 - on the Amiga. So over about 25-ish
years I'd learned it. I don't HAVE another 25 years to learn something
with documentation that requires extreme google-fu to find. (I did
manage to find a page that described /etc/sysconfig contents, FINALLY.
I've been looking for that off and /on for 5 years or more.



/usr/share/doc/initscripts-9.49.37/sysconfig.txt


"man --index" is needed methinks.


Pointers to that list in the documentation for RHEL tuned systemd
would be a good thing.)


It's not a systemd directory - and it's a directory that systemd
upstream dislikes.


It is intimately involved with systemd as used on RHEL based systems.
Cross references can tie it all together in a nice logical package
with bows on it.


Indeed but it's provided by the initscripts package so it should be
the latter's responsibility to provide, for example, "man sysconfig"
but it never has. AFAIR, neither upstart in EL6 nor sysvinit in
previous EL versions referred to "/etc/sysconfig/" in their
documentation (just as they don't refer to "/etc/default/" on
Debian/Ubuntu).


There are signs that somebody goes through the man pages and RHEL documentation 
to tune aspects of the documentation, chiefly file locations, for the RHEL 
environment. That process probably should include initscripts documentation in 
the references where appropriate. It would be a nice value added component.


{^_^}

Re: Adventures with 7.2

[Tom H]

On Mon, Jan 2, 2017 at 5:06 PM, jdow  wrote:
> On 2017-01-02 08:47, Tom H wrote:
>> On Mon, Jan 2, 2017 at 6:42 AM, jdow  wrote:
>>> On 2017-01-02 01:35, David Sommerseth wrote:


 Anaconda is the installer. To be honest, I've never understood why
 anaconda needs to be installed on a final production server. The
 production boxes I have where firewalld is uninstalled also have no
 anaconda installed. And these boxes do get their proper updates
 through yum regardless.
>>>
>>> It's not involved with system maintenance past the initial
>>> installation? I had the impression it was intimately involved with
>>> the system's overall configuration including updates. But, I must
>>> admit that it's not something I have dug into in any serious way.
>>> Thanks for the suggestion. I'll keep this option in mind. This is
>>> good to know.
>>
>> I don't have anaconda installed on any RHEL or RHEL clone system -
>> and never have.
>
> So I erased it with this fascinating transaction report excerpt:
>
> Running transaction
>   Erasing: initial-setup-gui-0.3.9.30-1.el7.x86_64
> 1/7
> warning: file
> /usr/lib/python2.7/site-packages/initial_setup/gui/spokes/eula.pyo: remove
> failed: No such file or directory
> warning: file
> /usr/lib/python2.7/site-packages/initial_setup/gui/spokes/eula.pyc: remove
> failed: No such file or directory
> warning: file
> /usr/lib/python2.7/site-packages/initial_setup/gui/spokes/eula.py: remove
> failed: No such file or directory
> warning: file
> /usr/lib/python2.7/site-packages/initial_setup/gui/spokes/eula.glade: remove
> failed: No such file or directory
>   Erasing: anaconda-gui-21.48.22.56-1.sl7.1.x86_64
> 2/7
>   Erasing: initial-setup-0.3.9.30-1.el7.x86_64
> 3/7
> warning: file
> /usr/lib/python2.7/site-packages/initial_setup/tui/spokes/eula.pyo: remove
> failed: No such file or directory
> warning: file
> /usr/lib/python2.7/site-packages/initial_setup/tui/spokes/eula.pyc: remove
> failed: No such file or directory
> warning: file
> /usr/lib/python2.7/site-packages/initial_setup/tui/spokes/eula.py: remove
> failed: No such file or directory
>   Erasing: anaconda-core-21.48.22.56-1.sl7.1.x86_64
> 4/7
>   Erasing: anaconda-tui-21.48.22.56-1.sl7.1.x86_64
> 5/7
>   Erasing: firewall-config-0.4.3.2-8.el7.noarch
> 6/7
>   Erasing: firewalld-0.4.3.2-8.el7.noarch
> 7/7
> warning: /etc/firewalld/lockdown-whitelist.xml saved as
> /etc/firewalld/lockdown-whitelist.xml.rpmsave
>
> That smells amusing and puzzling but not dangerous to me.

So it's not fully or properly installed, :) and :(


> Thanks for the information.

You're welcome.

Re: Adventures with 7.2

[Tom H]

On Mon, Jan 2, 2017 at 4:58 PM, jdow  wrote:
> On 2017-01-02 07:26, Tom H wrote:
>> On Mon, Jan 2, 2017 at 4:12 AM, jdow  wrote:
>>>
>>> The SYS5 stuff in 6.x and prior lacked flexibility, to be sure. It was
>>> simple enough that figuring out what was going on became easy. And
>>> where the documentation failed the workarounds were not all that
>>> difficult. But, then,the first 'ix I played with was one of the first
>>> commercial renditions of SVR4 - on the Amiga. So over about 25-ish
>>> years I'd learned it. I don't HAVE another 25 years to learn something
>>> with documentation that requires extreme google-fu to find. (I did
>>> manage to find a page that described /etc/sysconfig contents, FINALLY.
>>> I've been looking for that off and /on for 5 years or more.
>>
>>
>> /usr/share/doc/initscripts-9.49.37/sysconfig.txt
>
> "man --index" is needed methinks.
>
>>> Pointers to that list in the documentation for RHEL tuned systemd
>>> would be a good thing.)
>>
>> It's not a systemd directory - and it's a directory that systemd
>> upstream dislikes.
>
> It is intimately involved with systemd as used on RHEL based systems.
> Cross references can tie it all together in a nice logical package
> with bows on it.

Indeed but it's provided by the initscripts package so it should be
the latter's responsibility to provide, for example, "man sysconfig"
but it never has. AFAIR, neither upstart in EL6 nor sysvinit in
previous EL versions referred to "/etc/sysconfig/" in their
documentation (just as they don't refer to "/etc/default/" on
Debian/Ubuntu).

Re: Adventures with 7.2

[Tom H]

On Mon, Jan 2, 2017 at 4:56 PM, jdow  wrote:
> On 2017-01-02 06:16, Tom H wrote:
>> On Mon, Jan 2, 2017 at 4:03 AM, jdow  wrote:
>>>
>>> systemctl unmask firewalld failed.
>>
>>
>> I run "systemctl disable firewalld" before running "systemctl unmask
>> firewalld" because otherwise the logs have the "firewalld is masked"
>> messages.
>
> Thought I did it in that order. But I'm not sure. (stop, disable,
> unmask.) I believe I also noticed that with it stopped I'd suddenly
> find a mishmash of my firewall and firewalld's firewall. Firewalld had
> started back up. So that might have left me in a "smash it over the
> head" frame of mind. I've discovered with the projects I worked on
> that if there is a command like mask it would stop, disable, then put
> a very heavy stone coffin around it. (I'd drive the stake through it,
> last, only if "uninstall" was indicated.) So it's likely I could have
> made a rash assumption somewhere. I need to remember that's doing
> multiple "things" in one command which is not the 'ix way, I suppose.
>>
>> Did you run "systemctl enable firewalld" after running "systemctl
>> unmask firewalld"? Having to re-install firewalld doesn't make sense.
>
> Indeed, it didn't make sense to me either. I got the same error
> message that was flopping around in the logs.

I've screwed up on Fedora and SL when masking firewalld before
disabling it because masking it doesn't remove the symlink in
"/etc/systemd/system/basic.target.wants/" or the dbus symlink in
"/etc/systemd/system/".

Re: Adventures with 7.2

[jdow]

On 2017-01-02 08:47, Tom H wrote:

On Mon, Jan 2, 2017 at 6:42 AM, jdow  wrote:

On 2017-01-02 01:35, David Sommerseth wrote:


Anaconda is the installer. To be honest, I've never understood why
anaconda needs to be installed on a final production server. The
production boxes I have where firewalld is uninstalled also have no
anaconda installed. And these boxes do get their proper updates
through yum regardless.


It's not involved with system maintenance past the initial
installation? I had the impression it was intimately involved with the
system's overall configuration including updates. But, I must admit
that it's not something I have dug into in any serious way. Thanks for
the suggestion. I'll keep this option in mind. This is good to know.


I don't have anaconda installed on any RHEL or RHEL clone system - and
never have.


So I erased it with this fascinating transaction report excerpt:
Running transaction
  Erasing: initial-setup-gui-0.3.9.30-1.el7.x86_64  1/7
warning: file 
/usr/lib/python2.7/site-packages/initial_setup/gui/spokes/eula.pyo: remove 
failed: No such file or directory
warning: file 
/usr/lib/python2.7/site-packages/initial_setup/gui/spokes/eula.pyc: remove 
failed: No such file or directory
warning: file /usr/lib/python2.7/site-packages/initial_setup/gui/spokes/eula.py: 
remove failed: No such file or directory
warning: file 
/usr/lib/python2.7/site-packages/initial_setup/gui/spokes/eula.glade: remove 
failed: No such file or directory

  Erasing: anaconda-gui-21.48.22.56-1.sl7.1.x86_64  2/7
  Erasing: initial-setup-0.3.9.30-1.el7.x86_64  3/7
warning: file 
/usr/lib/python2.7/site-packages/initial_setup/tui/spokes/eula.pyo: remove 
failed: No such file or directory
warning: file 
/usr/lib/python2.7/site-packages/initial_setup/tui/spokes/eula.pyc: remove 
failed: No such file or directory
warning: file /usr/lib/python2.7/site-packages/initial_setup/tui/spokes/eula.py: 
remove failed: No such file or directory

  Erasing: anaconda-core-21.48.22.56-1.sl7.1.x86_64 4/7
  Erasing: anaconda-tui-21.48.22.56-1.sl7.1.x86_64  5/7
  Erasing: firewall-config-0.4.3.2-8.el7.noarch 6/7
  Erasing: firewalld-0.4.3.2-8.el7.noarch   7/7
warning: /etc/firewalld/lockdown-whitelist.xml saved as 
/etc/firewalld/lockdown-whitelist.xml.rpmsave


That smells amusing and puzzling but not dangerous to me.

Thanks for the information.

{^_^}

Re: Adventures with 7.2

[jdow]

On 2017-01-02 07:26, Tom H wrote:

On Mon, Jan 2, 2017 at 4:12 AM, jdow  wrote:



The SYS5 stuff in 6.x and prior lacked flexibility, to be sure. It was
simple enough that figuring out what was going on became easy. And
where the documentation failed the workarounds were not all that
difficult. But, then,the first 'ix I played with was one of the first
commercial renditions of SVR4 - on the Amiga. So over about 25-ish
years I'd learned it. I don't HAVE another 25 years to learn something
with documentation that requires extreme google-fu to find. (I did
manage to find a page that described /etc/sysconfig contents, FINALLY.
I've been looking for that off and /on for 5 years or more.


/usr/share/doc/initscripts-9.49.37/sysconfig.txt


"man --index" is needed methinks.


Pointers to that list in the documentation for RHEL tuned systemd
would be a good thing.)


It's not a systemd directory - and it's a directory that systemd
upstream dislikes.


It is intimately involved with systemd as used on RHEL based systems. Cross 
references can tie it all together in a nice logical package with bows on it.


{^_-}

Re: Adventures with 7.2

[jdow]

On 2017-01-02 06:16, Tom H wrote:

On Mon, Jan 2, 2017 at 4:03 AM, jdow  wrote:


systemctl unmask firewalld failed.


I run "systemctl disable firewalld" before running "systemctl unmask
firewalld" because otherwise the logs have the "firewalld is masked"
messages.


Thought I did it in that order. But I'm not sure. (stop, disable, unmask.) I 
believe I also noticed that with it stopped I'd suddenly find a mishmash of my 
firewall and firewalld's firewall. Firewalld had started back up. So that might 
have left me in a "smash it over the head" frame of mind. I've discovered with 
the projects I worked on that if there is a command like mask it would stop, 
disable, then put a very heavy stone coffin around it. (I'd drive the stake 
through it, last, only if "uninstall" was indicated.) So it's likely I could 
have made a rash assumption somewhere. I need to remember that's doing multiple 
"things" in one command which is not the 'ix way, I suppose.



Did you run "systemctl enable firewalld" after running "systemctl
unmask firewalld"? Having to re-install firewalld doesn't make sense.


Indeed, it didn't make sense to me either. I got the same error message that was 
flopping around in the logs.


{^_^}

Re: Adventures with 7.2

[Tom H]

On Mon, Jan 2, 2017 at 6:42 AM, jdow  wrote:
> On 2017-01-02 01:35, David Sommerseth wrote:
>>
>> Anaconda is the installer. To be honest, I've never understood why
>> anaconda needs to be installed on a final production server. The
>> production boxes I have where firewalld is uninstalled also have no
>> anaconda installed. And these boxes do get their proper updates
>> through yum regardless.
>
> It's not involved with system maintenance past the initial
> installation? I had the impression it was intimately involved with the
> system's overall configuration including updates. But, I must admit
> that it's not something I have dug into in any serious way. Thanks for
> the suggestion. I'll keep this option in mind. This is good to know.

I don't have anaconda installed on any RHEL or RHEL clone system - and
never have.

Re: Adventures with 7.2

[Tom H]

On Mon, Jan 2, 2017 at 4:00 AM, Nico Kadel-Garcia  wrote:
>
> Number of man pages is not the same as good documentation. Part of the
> difficulty of documenting systemd is its sprawl into different systems
> that have nothing to do with daemon management itself, including
> logging, DHCP, network configuration, automounting, and more recently
> trying to replace SELinux with "brilliant security changes!!!" such as
> the ill-fated "KillUserProcess" tool that kills all background
> processes when a user logs out and which breaks nohup, screen, and tux.

"KillUserProcesses=yes" isn't replacing selinux, it's ensuring that
all freedesktop and DE stuff is killed when a user logs out.

Re: Adventures with 7.2

[Tom H]

On Mon, Jan 2, 2017 at 4:24 AM, jdow  wrote:
>
> Did the second half. The first half had a large collection of dependencies
> that would be removed as well, little things like "anaconda-core". Erm, that
> might not be a good thing. I'm not interested in throwing the system into
> the dark ages.

You don't need anaconda-core on a running system. It's the installer!

Re: Adventures with 7.2

[Tom H]

On Mon, Jan 2, 2017 at 4:12 AM, jdow  wrote:


> The SYS5 stuff in 6.x and prior lacked flexibility, to be sure. It was
> simple enough that figuring out what was going on became easy. And
> where the documentation failed the workarounds were not all that
> difficult. But, then,the first 'ix I played with was one of the first
> commercial renditions of SVR4 - on the Amiga. So over about 25-ish
> years I'd learned it. I don't HAVE another 25 years to learn something
> with documentation that requires extreme google-fu to find. (I did
> manage to find a page that described /etc/sysconfig contents, FINALLY.
> I've been looking for that off and /on for 5 years or more.

/usr/share/doc/initscripts-9.49.37/sysconfig.txt


> Pointers to that list in the documentation for RHEL tuned systemd
> would be a good thing.)

It's not a systemd directory - and it's a directory that systemd
upstream dislikes.

Re: Adventures with 7.2

[Tom H]

On Mon, Jan 2, 2017 at 4:03 AM, jdow  wrote:
>
> systemctl unmask firewalld failed.

I run "systemctl disable firewalld" before running "systemctl unmask
firewalld" because otherwise the logs have the "firewalld is masked"
messages.

Did you run "systemctl enable firewalld" after running "systemctl
unmask firewalld"? Having to re-install firewalld doesn't make sense.

Re: Adventures with 7.2

[David Sommerseth]

On 02/01/17 12:51, jdow wrote:
> 
> Systemd has a steep and long learning curve, it appears. So a good GUI
> manager for it might be helpful, especially if it had some graphical
> features as well as text representations. The old init stuff was easier
> for somebody not making a career of the whole thing. If I was paid to
> sysadmin I'd dig in more than I can now. Other things are more fun for
> somebody not quite retired.

I believe the Cockpit project [1] is a step in that direction.  There
are even some packages available in the EL7 repos already.  It depends
on systemd and D-Bus to function, and can be extended to manage anything
which uses the the D-Bus.  Plus you can manage multiple servers via the
same interface.

[1] 

A few presentations on Cockpit can be found on youtube as well, like
these ones:

Cockpit: What's New and What's Next (Feb 2016)


Cockpit:  Modern Server User Interface (Feb 2015)
https://www.youtube.com/watch?v=97l1qf2sZtk


Towards the end of Januar, another devconf.cz [2] conference is
happening, and there might be yet another presentation on Cockpit, in
addition to probably also some systemd related ones.

[2] 


-- 
kind regards,

David Sommerseth

Re: Adventures with 7.2

[jdow]

On 2017-01-02 02:30, David Sommerseth wrote:
...

Holding grudges against people for their behaviour instead of
trying to get a grip of their overall goal is not really much helpful in
the long run.


That's why I gritted my teeth and dug in even if I just needed to make one 
system do what I want so I can get on with other things. Reading your note I put 
together my thoughts a little. It seems to be (rightly?) oriented towards 
systems developers and large system sysadmins with few handles for somebody who 
needs something just a little out of the ordinary so she can get back to playing 
with software defined radios and video presentation software. (Both are PAINFUL 
to write; but, having written is a world class wonderful feeling.)


{o.o}

Re: Adventures with 7.2

[jdow]

On 2017-01-02 01:47, David Sommerseth wrote:

On 02/01/17 10:03, jdow wrote:


I also found that I had no way I could find to tell systemd to bring up
a daemon as a relatively unprivileged user rather than root. Running
some services at root privileges makes me nervous even with SELinux in
place and active.


$ man systemd.exec

   User=, Group=
   Sets the Unix user or group that the
   processes are executed as,
   respectively. Takes a single user or
   group name or ID as argument. If no
   group is set, the default group of the
   user is chosen.


When I tried it I seemed to get unexpected results - subversion apparently 
insisted on remaining in the root privilege level. I may not have found the 
right place to put that into the xxx.service file. I found User=/Group= but the 
application of this remained obscure. I tried it under the [Service] heading. In 
retrospect does the order of placement under one of those headers make a difference?



Which translates to providing User=/Group= in the [service] section of a
unit file.


"Unit" is a bit of jargon that was not apparent at first. (hyperlinks work. It 
would be nice for people to use them more in HTML documentation first use in a 
section. {^_-})



Other useful settings for hardening a service are Capabilities=,
SecureBits=, PrivateTmp=, PrivateDevices=,  PrivateNetwork=,
ProtectSystem=, ProtectHome=, RestrictAddressFamilies=,
ReadWriteDirectories=, ReadOnlyDirectories= and InaccessibleDirectories=
... all documented in systemd.exec.

And then there is Restart= which is fairly useful and to get a similar
behaviour to daemontools, you can look into Type=simple (which is the
default if not provided).  These are found in systemd.service.

Getting a grip of the systemd man page hierarchy can be useful though.
I generally find all the information I need when working on unit files
for services in systemd.unit, systemd.service, systemd.exec and
systemd.kill.  That usually covers most of the life cycle of a service.


Systemd has a steep and long learning curve, it appears. So a good GUI manager 
for it might be helpful, especially if it had some graphical features as well as 
text representations. The old init stuff was easier for somebody not making a 
career of the whole thing. If I was paid to sysadmin I'd dig in more than I can 
now. Other things are more fun for somebody not quite retired.


{^_-}

Re: Adventures with 7.2

[jdow]

On 2017-01-02 01:35, David Sommerseth wrote:

On 02/01/17 10:24, jdow wrote:

On 2017-01-01 14:24, David Sommerseth wrote:

On 01/01/17 01:28, jdow wrote:


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.


# yum erase firewalld
# yum install iptables-services


Did the second half. The first half had a large collection of
dependencies that would be removed as well, little things like
"anaconda-core". Erm, that might not be a good thing. I'm not interested
in throwing the system into the dark ages. I just want to use some
iptables features that it firewalld doesn't seem to be able to approach.


I've discussed several details with the firewalld developers (reasonable
group of people, btw) and they do acknowledge that firewalld do have
some challenges, also in regards to logging.

The approach I've recommended have been deployed on two production systems.

Btw, the official documentation provides this guidance:



I found that page. I've had one indication that keeping firewalld disabled may 
be a chore through a reboot. It's on my todo list to solve.



But remove Anaconda? K!


Anaconda is the installer.  To be honest, I've never understood why
anaconda needs to be installed on a final production server.  The
production boxes I have where firewalld is uninstalled also have no
anaconda installed.  And these boxes do get their proper updates through
yum regardless.


It's not involved with system maintenance past the initial installation? I had 
the impression it was intimately involved with the system's overall 
configuration including updates. But, I must admit that it's not something I 
have dug into in any serious way. Thanks for the suggestion. I'll keep this 
option in mind. This is good to know.


{^_^}

Re: Adventures with 7.2

[David Sommerseth]

On 02/01/17 10:00, Nico Kadel-Garcia wrote:
> On Sun, Jan 1, 2017 at 5:19 PM, David Sommerseth
>  wrote:
>> On 01/01/17 01:28, jdow wrote:
>>> systemd sucks dead bunnies through garden hoses - chiefly due to nearly
>>> totally absent documentation.
>> Seriously?
>>
>> $ locate systemd | grep /usr/share/man/ | wc -l
>> 145
> Number of man pages is not the same as good documentation. 

Fair point.  But from all my experience with the man pages in systemd,
they are well written and provides all the information you do need to
understand what the various unit files does.  But as always, YMMV.

> Part of the
> difficulty of documenting systemd is its sprawl into different systems
> that have nothing to do with daemon management itself, including
> logging, DHCP, network configuration, automounting,

I'd say that logging has everything to do with service management.
upstart and the prior alternatives did very bad logging of services
starting up at boot, where I just too often lost important details
services wrote directly to the console and was never caught in any log
files.  Systemds journal captures even those.

Automounting may not be strictly daemon (or service) management, but
again I find the documentation (systemd.automount and systemd.mount man
pages) providing the information I need.  And the autofs service is a
very different chapter, which is a daemon managed by systemd.

But again, all of these new approaches can in the very most cases be
disabled (or disables itself) if you install the packages you're used
to.  F.ex. all my EL7 systems run with rsyslogd and the journal, without
any issues.  All the servers run ntpd which disabled chronyd.  And the
network confniguration have not arrived in EL7 yet, so for that I don't
worry yet.

> and more recently
> trying to replace SELinux with "brilliant security changes!!!" such as
> the ill-fated "KillUserProcess" tool that kills all background
> processes when a user logs out and which breaks nohup, screen, and
> tux.

That's more a matter of perspective.  On some systems I do see that
KillUserProcesses= is not a good idea.  But on most systems I've used,
it is a very good idea that user sessions are properly cleaned up and
don't leave stray processes running in the background.  And the proper
way to tell systemd's login manager that a user is going to have some
processes running after logout, there is 'loginctl enable-linger'.  If
you dislike it, you can always switch back to the old behaviour, by
setting KillUserProcesses= in logind.conf yourself.

Complaining that systemd changes the behaviours of the old way of doing
things are less than useful when considering all the various issues with
how systems where managed before systemd.  From my perspective, systemd
is far more capable of managing a system, both in short and long time
perspective, doing things how they should have been done in the
beginning.  And yes, daemontools had some good merits, and I see that
systemd actually brings in several of the ideas from there (but not
implemented in the same way, far from it).

Unfortunately, it too often seems that people complain about systemd
more due to the personality of the core systemd developers and their
bruteforce approach of introducing systemd into Fedora 6-7 years ago,
more than actually looking at the benefits systemd provides in a system
today.  Holding grudges against people for their behaviour instead of
trying to get a grip of their overall goal is not really much helpful in
the long run.


-- 
kind regards,

David Sommerseth

Re: Adventures with 7.2

[David Sommerseth]

On 02/01/17 10:03, jdow wrote:
> 
> I also found that I had no way I could find to tell systemd to bring up
> a daemon as a relatively unprivileged user rather than root. Running
> some services at root privileges makes me nervous even with SELinux in
> place and active.

$ man systemd.exec

   User=, Group=
   Sets the Unix user or group that the
   processes are executed as,
   respectively. Takes a single user or
   group name or ID as argument. If no
   group is set, the default group of the
   user is chosen.

Which translates to providing User=/Group= in the [service] section of a
unit file.

Other useful settings for hardening a service are Capabilities=,
SecureBits=, PrivateTmp=, PrivateDevices=,  PrivateNetwork=,
ProtectSystem=, ProtectHome=, RestrictAddressFamilies=,
ReadWriteDirectories=, ReadOnlyDirectories= and InaccessibleDirectories=
... all documented in systemd.exec.

And then there is Restart= which is fairly useful and to get a similar
behaviour to daemontools, you can look into Type=simple (which is the
default if not provided).  These are found in systemd.service.

Getting a grip of the systemd man page hierarchy can be useful though.
I generally find all the information I need when working on unit files
for services in systemd.unit, systemd.service, systemd.exec and
systemd.kill.  That usually covers most of the life cycle of a service.


-- 
kind regards,

David Sommerseth

Re: Adventures with 7.2

[David Sommerseth]

On 02/01/17 10:24, jdow wrote:
> On 2017-01-01 14:24, David Sommerseth wrote:
>> On 01/01/17 01:28, jdow wrote:
>>>
>>> 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.
>>
>> # yum erase firewalld
>> # yum install iptables-services
> 
> Did the second half. The first half had a large collection of
> dependencies that would be removed as well, little things like
> "anaconda-core". Erm, that might not be a good thing. I'm not interested
> in throwing the system into the dark ages. I just want to use some
> iptables features that it firewalld doesn't seem to be able to approach.

I've discussed several details with the firewalld developers (reasonable
group of people, btw) and they do acknowledge that firewalld do have
some challenges, also in regards to logging.

The approach I've recommended have been deployed on two production systems.

Btw, the official documentation provides this guidance:


> But remove Anaconda? K!

Anaconda is the installer.  To be honest, I've never understood why
anaconda needs to be installed on a final production server.  The
production boxes I have where firewalld is uninstalled also have no
anaconda installed.  And these boxes do get their proper updates through
yum regardless.


-- 
kind regards,

David Sommerseth

Re: Adventures with 7.2

[jdow]

On 2017-01-01 14:24, David Sommerseth wrote:

On 01/01/17 01:28, jdow wrote:


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.


# yum erase firewalld
# yum install iptables-services


Did the second half. The first half had a large collection of dependencies that 
would be removed as well, little things like "anaconda-core". Erm, that might 
not be a good thing. I'm not interested in throwing the system into the dark 
ages. I just want to use some iptables features that it firewalld doesn't seem 
to be able to approach. It's gui doesn't even seem to have a way to turn SOME 
logging on leaving most logging off. That's rude. (I find I am even eschewing 
the iptables-services tools. I'm using the dhclient script capability to reset 
the firewall when a new address is assigned. The actual firewall design right 
now closely resembles that produced by firewalld. It was useful for a template 
for retuning the firewall's features.)


This little stanza is one I've been using since my first iptables setup:
$IPT -t filter -A IN_public_deny -p tcp --dport ssh --syn -m recent --name 
ssh_attack --rcheck --seconds 90 --hitcount 1 -j LOG --log-prefix 'SSH2 REJECT: 
' --log-level info
$IPT -t filter -A IN_public_deny -p tcp --dport ssh --syn -m recent --name 
ssh_attack --rcheck --seconds 90 --hitcount 1 -j REJECT --reject-with tcp-reset
$IPT -t filter -A IN_public_deny -p tcp --dport ssh --syn -m recent --name 
ssh_attack --set


A given site cannot feed a SYN packet to the ssh port more often than once every 
90 seconds. It makes password guessing rather time consuming. Firewalld 
documentation was not clear how I'd add that into its firewall via the gui, 
especially if it is conditional to a tiny configuration file in /etc to disable 
all ingress ports or open them up and how to open them up. Open when traveling. 
Close when home.


But remove Anaconda? K!

{o.o}

Re: Adventures with 7.2

[jdow]

On 2017-01-02 01:00, Nico Kadel-Garcia wrote:

On Sun, Jan 1, 2017 at 5:19 PM, David Sommerseth
 wrote:

On 01/01/17 01:28, jdow wrote:

...

I don't mind flame wars of controversial topics, but let it at least
start with proper facts ... In my experience, systemd is far better
documented than any other init system I've used over the last 15+ years
or so.


daemontools was much lighter, much cleaner, and well documented. It
never took off due to some unfortunate copyright policies by its
author. It's too late to switch now, because of the integration of
more modern logging with systemd.


The SYS5 stuff in 6.x and prior lacked flexibility, to be sure. It was simple 
enough that figuring out what was going on became easy. And where the 
documentation failed the workarounds were not all that difficult. But, then,the 
first 'ix I played with was one of the first commercial renditions of SVR4 - on 
the Amiga. So over about 25-ish years I'd learned it. I don't HAVE another 25 
years to learn something with documentation that requires extreme google-fu to 
find. (I did manage to find a page that described /etc/sysconfig contents, 
FINALLY. I've been looking for that off and on for 5 years or more. {^_-} 
Pointers to that list in the documentation for RHEL tuned systemd would be a 
good thing.)


I can see the improvement systemd gives over the old stuff. But, I reserve the 
right to bitch when the learning curve is made artificially steep. (Then I get 
down to business and worry the problems to a solution.)


{^_-}

Re: Adventures with 7.2

[jdow]

On 2017-01-01 14:19, David Sommerseth wrote:

On 01/01/17 01:28, jdow wrote:

systemd sucks dead bunnies through garden hoses - chiefly due to nearly
totally absent documentation.


Seriously?

$ locate systemd | grep /usr/share/man/ | wc -l
145




I don't mind flame wars of controversial topics, but let it at least
start with proper facts ... In my experience, systemd is far better
documented than any other init system I've used over the last 15+ years
or so.


Sometimes frustration breeds outbursts. At least I can generally tell which 
pages google coughs up are gold, which are lead, and which are highly 
radioactive, So I worked by way though about a dozen setup issues made worse by 
documentation that was not as clear as it might be, charitably speaking. The 
results are well worth the pain. I'd rather not have had the pain, or at least 
20 dB less pain.


At the level I wanted it the systemd man pages seemed uninformative. When I 
searched on the web it was a pain to put pieces together in a manner that made 
sense. I'd played with it at a "get a test system up" level and as far as I went 
it was fine. It required a LOT of effort to figure out where important data was 
stored.


systemctl unmask firewalld failed. Reinstalling firewalld got it back so I could 
shut up an annoying 32 minute repeat of a message saying it could not be 
started. Something is too dumb to take no for an answer.


I also found that I had no way I could find to tell systemd to bring up a daemon 
as a relatively unprivileged user rather than root. Running some services at 
root privileges makes me nervous even with SELinux in place and active.


Once I learned, by experimentation as much as documentation, systemd is nice 
with some good concepts in it. With better documentation I'd give it an 8 or so 
out of 10 for good. With the documentation, which seemed self-contradictory with 
terms that showed no direct relationship to what they labeled, was more 
obfuscation than clarification. I liken it to, "If you know what you are doing 
the documentation can explain to you what to do." It's like the radio in the '67 
Corvette we had. You had to have the radio out of the car to get at the screws 
you had to remove to get the radio out. (I finally found a very flat offset 
screwdriver and teased the screw out and back in.)


I also noticed with 7.2 there is a general reduction in GUI support for 
configuration. A grump is the (apparent) inability to explain to the famn dool 
thing I like and have gotten used to my dates reading 20170102 - in a nice 
lexically sortable format. A problem is that there is no GUI I found to display 
all loaded services on the machine and whether they are enabled or not and 
whether they are active or not. Only a CLI tool exists, which I like. But, it's 
clumsy for performing survey searches for what's running. And in general 
documentation seems to be slowly going downhill from what I remember from the 
early 2000s. (Those were an improvement over the 1990s.)


So configuring 7.2 has been a king size hassle. On the whole it seems to 
performing the tasks asked of it very well. In that sense it is a very 
worthwhile improvement over 6.x. It's a mixed bag; and, I had to let a little 
gas escape over the state of documentation, even on the online RHEL documentation


(The REAL winge I have is about subversion not being able to drop privilege 
after it starts and run as a user rather than root. That is shameful. And I am a 
tad hesitant to spend the time just now to figure out how to chroot it. And even 
THEN I'd probably try to run it at a user level privilege rather than root. I 
like layered defense.)


As an aside I wonder if anybody alive can really tame SELinux (or MS ACLs) and 
make it something a fairly experienced user/developer could fiddle with.


{^_^}

Re: Adventures with 7.2

[Nico Kadel-Garcia]

On Sun, Jan 1, 2017 at 5:19 PM, David Sommerseth
 wrote:
> On 01/01/17 01:28, jdow wrote:
>> systemd sucks dead bunnies through garden hoses - chiefly due to nearly
>> totally absent documentation.
>
> Seriously?
>
> $ locate systemd | grep /usr/share/man/ | wc -l
> 145

Number of man pages is not the same as good documentation. Part of the
difficulty of documenting systemd is its sprawl into different systems
that have nothing to do with daemon management itself, including
logging, DHCP, network configuration, automounting, and more recently
trying to replace SELinux with "brilliant security changes!!!" such as
the ill-fated "KillUserProcess" tool that kills all background
processes when a user logs out and which breaks nohup, screen, and
tux.

> 
>
>
> I don't mind flame wars of controversial topics, but let it at least
> start with proper facts ... In my experience, systemd is far better
> documented than any other init system I've used over the last 15+ years
> or so.

daemontools was much lighter, much cleaner, and well documented. It
never took off due to some unfortunate copyright policies by its
author. It's too late to switch now, because of the integration of
more modern logging with systemd.

> --
> kind regards,
>
> David Sommerseth

Re: Adventures with 7.2

[David Sommerseth]

On 01/01/17 01:28, jdow wrote:
> 
> 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.

# yum erase firewalld
# yum install iptables-services

Now you're back to the old way of firewall management.


-- 
kind regards,

David Sommerseth

Re: Adventures with 7.2

[David Sommerseth]

On 01/01/17 01:28, jdow wrote:
> systemd sucks dead bunnies through garden hoses - chiefly due to nearly
> totally absent documentation.

Seriously?

$ locate systemd | grep /usr/share/man/ | wc -l
145




I don't mind flame wars of controversial topics, but let it at least
start with proper facts ... In my experience, systemd is far better
documented than any other init system I've used over the last 15+ years
or so.


-- 
kind regards,

David Sommerseth