WIP: firewalld system containers #150
Conversation
The container is still work in progress. The docker file can be compiled successfully. However, when starting the service via systemctl, the command will time out eventually. I have a few thoughts for debugging, will take a while to figure it out. Have it here first for some feedback :). (will modify the commit message once lifting the WIP )
firewalld/Dockerfile
Outdated
| mkdir -p /exports/hostfs/etc/dbus-1/system.d && \ | ||
| cp /etc/sysconfig/firewalld /exports/hostfs/etc/sysconfig && \ | ||
| # Copy all the polkit related files into current polkit | ||
| cp /usr/share/polkit-1/actions/org.fedoraproject.FirewallD1.* /exports/hostfs/usr/share/polkit-1/actions && \ |
There was a problem hiding this comment.
is there another location we can use instead of "/usr/share"? Otherwise this would not work on Atomic Host
There was a problem hiding this comment.
Good point :D.
yea ...., I think it would be hard to do so on Atomic Host to make a change to read only /usr .. IMO, the way how package layering works in Atomic Host is that we make a new bootable deployment which contains the completely new /usr with the package installed ( package layering avoided modifying current /usr directly ). So in this case, the polkit related files will still be in /usr/share, except that it is inside a deployment folder..
After package layering firewalld on atomic host, the location of policy is:
/sysroot/ostree/deploy/fedora-atomic/deploy/c3d2bde48ccd610057a7d7bb8dbb883bc23a86b61fbef74c934e14253ba7f475.0/usr/share/polkit-1/actions/org.fedoraproject.FirewallD1.policy
So, I think what we could possibly do on atomic host is that..
1: we first check if we are on an atomic host or an ostree managed OS?
2: If we are, we find out where the current bootable deployment is (somehow), then we directly copy these files into that bootable deployment /usr directory. would that work? WDYT @giuseppe
There was a problem hiding this comment.
is it possible to configure polkit to look into another directory? We can probably change it to use /var/ or /etc instead of /usr/share. That will work on Atomic Host without the need of copying files to /usr and breaking the assumption it is read only.
firewalld/Dockerfile
Outdated
| mkdir -p /exports/hostfs/usr/lib/firewalld && \ | ||
| cp -r /usr/lib/firewalld/* /exports/hostfs/usr/lib/firewalld && \ | ||
| cp /usr/sbin/ebtables /exports/hostfs/usr/sbin/ && \ | ||
| cp /usr/sbin/ipset /exports/hostfs/sbin/ |
There was a problem hiding this comment.
let's not copy binaries (ebtables and ipset) outside of the container
There was a problem hiding this comment.
Yea... I agree it is ugly.. but currently I can't find a neat way to let firewalld find the binaries. During the execution of firewalld, it will call those binaries(ipset and ebatables) for checking.
https://github.com/firewalld/firewalld/blob/master/src/firewall/config/__init__.py.in#L105
https://github.com/firewalld/firewalld/blob/master/src/firewall/core/fw.py#L76
# commands used by backends
COMMANDS = {
"ipv4": "/usr/sbin/iptables",
"ipv4-restore": "/usr/sbin/iptables-restore",
"ipv6": "/usr/sbin/ip6tables",
"ipv6-restore": "/usr/sbin/ip6tables-restore",
"eb": "/usr/sbin/ebtables",
"eb-restore": "/usr/sbin/ebtables-restore",
"ipset": "/usr/sbin/ipset",
"modinfo": "/sbin/modinfo",
"modprobe": "/sbin/modprobe",
"rmmod": "/sbin/rmmod",
}
above is translated commands to loactions when opening firewalld code repo with pycharm
If I do not have those binaries copied to the host, there will be a WARNING message displayed in the log :(. Is there a good way to let firewalld use those commands while not copying the binaries of the commands to the host? :)
edit: it is also possible that I am having a misunderstanding of the concept. So, please correct me if I am wrong. :-)
There was a problem hiding this comment.
how is it using the binaries from the host? Isn't enough they are in the container? /usr is coming from the container
There was a problem hiding this comment.
After thinking + reading more documents, there are still a few doubts about the implementation. Any hints would be appreciated =).
/usr is coming from container
1: Then I am a bit confused about how systemd handles paths. I understand that the executable in /usr/bin/xxx will all first be resolved as /var/lib/containers/atomic/firewalld.0/rootfs/usr/bin/xx right? But what if /usr/bin/firewalld/ calls other binaries (e.g ipset), during its execution? Does systemd/runc still able to make the path canonical ( relative to the container's rootfs )?
However, do note this is just a general question about relative path concept, this is not in reply to the answer above.
2: The above confusion also leads to my next question. I found that without copying /usr/share/polkit-1/actions/xxx files into the host, the program will fail due to Access denied. But systemd will resolve the path for us right? Why it seems necessary to copy these policy files into host in order to resolve the access denied error ?
A lot of the decisions( like copying polkit and /usr/lib files) are made just because of try and error, that is why I am a bit tempting to understand the concept behind it. It will be great if there is a document to read through :p.
3: While looking at the files generated for firewalld. I see two important files related to dbus service. One is /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service and another one is
/etc/dbus-1/system.d/FirewallD.conf. ( those were used for dbus I believe)
Then, I think the normal way how firewalld works on the file system (based on inspection and analysis and some guessing) is that it launches dbus --> dbus checks the polkit rules ( uses conf file) and other policies --> dbus launches systemd service through the service file.
If that is the case, I am a bit unsure about how to link our service.template file to this dbus service. As, we had an extra layer of runc in between. I tested a bit with
[Service]
Type=dbus
BusName=org.fedoraproject.FirewallD1
ExecStart=$EXEC_START
ExecStop=$EXEC_STOP
Restart=on-failure
WorkingDirectory=$DESTDIR
RuntimeDirectory=${NAME}
will make the service being "active" status. (with type=notify, the service always hang ). But I am a bit unsure about if I did it correctly, and what will the drawbacks might be in the future. WDYT?
4: I am unsure about the relationship between dbus conf and service files, and their relationship when policy kit is involved. Is there any document that is recommended to read in order to shorten this knowledge gap?
Also, the service file /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service seems to be empty when installing onto a fresh container, probably due to the broken systemd on a container. Any solutions for that, and do we ever want to copy related service files (e.g polkit.service) onto the host?
Sorry for these many questions, the knowledge gap is huge for me at the beginning. I was not able to find any meaningful documents to help me make further progress =(. we can have a bluejean chat too if written reply takes too much time. More importantly, thanks for your time =)
There was a problem hiding this comment.
once the container runs, the process there has a visibility only on /var/lib/containers/atomic/firewalld.0/rootfs, that becomes '/'. Unless you call executables directly from the systemd service file (which you don't AFAICS), systemd doesn't have any knowledge of how the container looks like and what is inside.
We still need to copy the polkit files to the host and that is correct, since we are using polkit from the host and I think this part works already fine in your current version. I've played around with it and tried few different things, firewalld was working well.
"Type=dbus" means systemd consider the service started up once it acquires its name from the dbus connection. You are bind mounting the dbus socket to the container, so firewalld can do that in the same way as it would if running on the host.
The only part I'd like you to investigate is that we can use /etc/dbus-1/ instead of /usr/share for copying the dbus files, as copying files to /usr/share goes against the Atomic Host assumption of /usr being read only, even if we can circumvent it going into the /sysroot path.
And really no worries about the knowledge gap. You are doing a great job, take your time to understand the (too many) pieces involved. This is more important than being in a hurry to complete the patch.
There was a problem hiding this comment.
/usr/local is a special case, and it is writeable on Atomic Host, so it should work fine
There was a problem hiding this comment.
Ah, I see, I will try this out, been trying to fight against weird network error lately, sorry if it might take a while, and thanks for your suggestion =D.
There was a problem hiding this comment.
Sorry for the late response, did not get a chance to work on this until now. In the meantime, may I ask a few extra questions for clarification? Thanks in advance =)
1: how is /usr "read only" enforced on Atomic Host? (ostree managed systems). The root still can modify files in /usr right? In that case, won't it still "betrays" the concept of read only?
My guess: is it that at boot time, the image we actually read is not from current /, rather it is from /sysroot/ostree/deploy/fedora-atomic/deploy/xxx?
2: If copying files into /usr is not allowed except /usr/local/share, do we need to take care about files copied into /usr/lib as well?
My guess : /usr/lib is from /lib, but it is still writing to read only /usr, so we need to take care of it?
3: There are plenty of extra files listed when I did rpm -qpl xxx (package), some of them includes man pages info, or other related/sub binaries. For example, firewalld usually comes with firewall-cmd, do we need to worry about these files too?
My guess: those won't be necessary because what we want is only the firewalld's functionality( i.e: to create firewalls), and other files may not be needed to save space / dependency handling
These are doubts of mine, and I make some guesses to them, feel free to correct me if I happen to get it wrong :p. Thanks for your time =D.
Edit: 4: Another question, related to Q1 and Q2, will /etc changes also be effective after reboot on Atomic Host?
There was a problem hiding this comment.
-
/usris enforced to be read only by a readonly mountpoint. Only/usr/localis writeable: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html -
/usr/libis not writeable, what do we still need to copy there? -
we could copy firewall-cmd to the host (under /usr/local) but for now, let's not copy it and require users to use
atomic runfor launching the command within the container itself.
There was a problem hiding this comment.
/usr is enforced to be read only by a readonly mountpoint. Only /usr/local is writeable: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html
ah I see, yea, it makes sense now, so I assume that any changes made to the existing /usr/local
will be permanent right? (i.e visible after reboot)
/usr/lib is not writeable, what do we still need to copy there?
before, I want to copy those xml files into /usr/lib but later figured that /etc xml seem to work as well,
(files are got from rpm -qlp firewalld package). But I figured, those xml files can be copied to the /etc/firewalld as well, so I think we should be ok =).
/usr/lib/firewalld/helpers/Q.931.xml
/usr/lib/firewalld/helpers/RAS.xml
/usr/lib/firewalld/helpers/amanda.xml
/usr/lib/firewalld/helpers/ftp.xml
/usr/lib/firewalld/helpers/h323.xml
/usr/lib/firewalld/helpers/irc.xml
/usr/lib/firewalld/helpers/netbios-ns.xml
/usr/lib/firewalld/helpers/pptp.xml
/usr/lib/firewalld/helpers/sane.xml
/usr/lib/firewalld/helpers/sip.xml
/usr/lib/firewalld/helpers/snmp.xml
/usr/lib/firewalld/helpers/tftp.xml
/usr/lib/firewalld/icmptypes/address-unreachable.xml
/usr/lib/firewalld/icmptypes/bad-header.xml
/usr/lib/firewalld/icmptypes/beyond-scope.xml
/usr/lib/firewalld/icmptypes/communication-prohibited.xml
/usr/lib/firewalld/icmptypes/destination-unreachable.xml
/usr/lib/firewalld/icmptypes/echo-reply.xml
/usr/lib/firewalld/icmptypes/echo-request.xml
/usr/lib/firewalld/icmptypes/failed-policy.xml
/usr/lib/firewalld/icmptypes/fragmentation-needed.xml
/usr/lib/firewalld/icmptypes/host-precedence-violation.xml
/usr/lib/firewalld/icmptypes/host-prohibited.xml
/usr/lib/firewalld/icmptypes/host-redirect.xml
/usr/lib/firewalld/icmptypes/host-unknown.xml
/usr/lib/firewalld/icmptypes/host-unreachable.xml
/usr/lib/firewalld/icmptypes/ip-header-bad.xml
/usr/lib/firewalld/icmptypes/neighbour-advertisement.xml
/usr/lib/firewalld/icmptypes/neighbour-solicitation.xml
/usr/lib/firewalld/icmptypes/network-prohibited.xml
/usr/lib/firewalld/icmptypes/network-redirect.xml
/usr/lib/firewalld/icmptypes/network-unknown.xml
/usr/lib/firewalld/icmptypes/network-unreachable.xml
/usr/lib/firewalld/icmptypes/no-route.xml
/usr/lib/firewalld/icmptypes/packet-too-big.xml
/usr/lib/firewalld/icmptypes/parameter-problem.xml
/usr/lib/firewalld/icmptypes/port-unreachable.xml
/usr/lib/firewalld/icmptypes/precedence-cutoff.xml
/usr/lib/firewalld/icmptypes/protocol-unreachable.xml
/usr/lib/firewalld/icmptypes/redirect.xml
/usr/lib/firewalld/icmptypes/reject-route.xml
/usr/lib/firewalld/icmptypes/required-option-missing.xml
/usr/lib/firewalld/icmptypes/router-advertisement.xml
/usr/lib/firewalld/icmptypes/router-solicitation.xml
/usr/lib/firewalld/icmptypes/source-quench.xml
/usr/lib/firewalld/icmptypes/source-route-failed.xml
/usr/lib/firewalld/icmptypes/time-exceeded.xml
/usr/lib/firewalld/icmptypes/timestamp-reply.xml
/usr/lib/firewalld/icmptypes/timestamp-request.xml
/usr/lib/firewalld/icmptypes/tos-host-redirect.xml
/usr/lib/firewalld/icmptypes/tos-host-unreachable.xml
/usr/lib/firewalld/icmptypes/tos-network-redirect.xml
/usr/lib/firewalld/icmptypes/tos-network-unreachable.xml
/usr/lib/firewalld/icmptypes/ttl-zero-during-reassembly.xml
/usr/lib/firewalld/icmptypes/ttl-zero-during-transit.xml
/usr/lib/firewalld/icmptypes/unknown-header-type.xml
/usr/lib/firewalld/icmptypes/unknown-option.xml
/usr/lib/firewalld/ipsets/README
/usr/lib/firewalld/services/RH-Satellite-6.xml
/usr/lib/firewalld/services/amanda-client.xml
/usr/lib/firewalld/services/amanda-k5-client.xml
/usr/lib/firewalld/services/bacula-client.xml
/usr/lib/firewalld/services/bacula.xml
/usr/lib/firewalld/services/bitcoin-rpc.xml
/usr/lib/firewalld/services/bitcoin-testnet-rpc.xml
/usr/lib/firewalld/services/bitcoin-testnet.xml
/usr/lib/firewalld/services/bitcoin.xml
/usr/lib/firewalld/services/ceph-mon.xml
/usr/lib/firewalld/services/ceph.xml
/usr/lib/firewalld/services/cfengine.xml
/usr/lib/firewalld/services/condor-collector.xml
/usr/lib/firewalld/services/ctdb.xml
/usr/lib/firewalld/services/dhcp.xml
/usr/lib/firewalld/services/dhcpv6-client.xml
/usr/lib/firewalld/services/dhcpv6.xml
/usr/lib/firewalld/services/dns.xml
/usr/lib/firewalld/services/docker-registry.xml
/usr/lib/firewalld/services/dropbox-lansync.xml
/usr/lib/firewalld/services/elasticsearch.xml
/usr/lib/firewalld/services/freeipa-ldap.xml
/usr/lib/firewalld/services/freeipa-ldaps.xml
/usr/lib/firewalld/services/freeipa-replication.xml
/usr/lib/firewalld/services/freeipa-trust.xml
/usr/lib/firewalld/services/ftp.xml
/usr/lib/firewalld/services/ganglia-client.xml
/usr/lib/firewalld/services/ganglia-master.xml
/usr/lib/firewalld/services/high-availability.xml
/usr/lib/firewalld/services/http.xml
/usr/lib/firewalld/services/https.xml
/usr/lib/firewalld/services/imap.xml
/usr/lib/firewalld/services/imaps.xml
/usr/lib/firewalld/services/ipp-client.xml
/usr/lib/firewalld/services/ipp.xml
/usr/lib/firewalld/services/ipsec.xml
/usr/lib/firewalld/services/iscsi-target.xml
/usr/lib/firewalld/services/kadmin.xml
/usr/lib/firewalld/services/kerberos.xml
/usr/lib/firewalld/services/kibana.xml
/usr/lib/firewalld/services/klogin.xml
/usr/lib/firewalld/services/kpasswd.xml
/usr/lib/firewalld/services/kshell.xml
/usr/lib/firewalld/services/ldap.xml
/usr/lib/firewalld/services/ldaps.xml
/usr/lib/firewalld/services/libvirt-tls.xml
/usr/lib/firewalld/services/libvirt.xml
/usr/lib/firewalld/services/managesieve.xml
/usr/lib/firewalld/services/mdns.xml
/usr/lib/firewalld/services/mosh.xml
/usr/lib/firewalld/services/mountd.xml
/usr/lib/firewalld/services/ms-wbt.xml
/usr/lib/firewalld/services/mssql.xml
/usr/lib/firewalld/services/mysql.xml
/usr/lib/firewalld/services/nfs.xml
/usr/lib/firewalld/services/nrpe.xml
/usr/lib/firewalld/services/ntp.xml
/usr/lib/firewalld/services/openvpn.xml
/usr/lib/firewalld/services/ovirt-imageio.xml
/usr/lib/firewalld/services/ovirt-storageconsole.xml
/usr/lib/firewalld/services/ovirt-vmconsole.xml
/usr/lib/firewalld/services/pmcd.xml
/usr/lib/firewalld/services/pmproxy.xml
/usr/lib/firewalld/services/pmwebapi.xml
/usr/lib/firewalld/services/pmwebapis.xml
/usr/lib/firewalld/services/pop3.xml
/usr/lib/firewalld/services/pop3s.xml
/usr/lib/firewalld/services/postgresql.xml
/usr/lib/firewalld/services/privoxy.xml
/usr/lib/firewalld/services/proxy-dhcp.xml
/usr/lib/firewalld/services/ptp.xml
/usr/lib/firewalld/services/pulseaudio.xml
/usr/lib/firewalld/services/puppetmaster.xml
/usr/lib/firewalld/services/quassel.xml
/usr/lib/firewalld/services/radius.xml
/usr/lib/firewalld/services/rpc-bind.xml
/usr/lib/firewalld/services/rsh.xml
/usr/lib/firewalld/services/rsyncd.xml
/usr/lib/firewalld/services/samba-client.xml
/usr/lib/firewalld/services/samba.xml
/usr/lib/firewalld/services/sane.xml
/usr/lib/firewalld/services/sip.xml
/usr/lib/firewalld/services/sips.xml
/usr/lib/firewalld/services/smtp-submission.xml
/usr/lib/firewalld/services/smtp.xml
/usr/lib/firewalld/services/smtps.xml
/usr/lib/firewalld/services/snmp.xml
/usr/lib/firewalld/services/snmptrap.xml
/usr/lib/firewalld/services/spideroak-lansync.xml
/usr/lib/firewalld/services/squid.xml
/usr/lib/firewalld/services/ssh.xml
/usr/lib/firewalld/services/synergy.xml
/usr/lib/firewalld/services/syslog-tls.xml
/usr/lib/firewalld/services/syslog.xml
/usr/lib/firewalld/services/telnet.xml
/usr/lib/firewalld/services/tftp-client.xml
/usr/lib/firewalld/services/tftp.xml
/usr/lib/firewalld/services/tinc.xml
/usr/lib/firewalld/services/tor-socks.xml
/usr/lib/firewalld/services/transmission-client.xml
/usr/lib/firewalld/services/vdsm.xml
/usr/lib/firewalld/services/vnc-server.xml
/usr/lib/firewalld/services/wbem-https.xml
/usr/lib/firewalld/services/xmpp-bosh.xml
/usr/lib/firewalld/services/xmpp-client.xml
/usr/lib/firewalld/services/xmpp-local.xml
/usr/lib/firewalld/services/xmpp-server.xml
/usr/lib/firewalld/xmlschema/check.sh
/usr/lib/firewalld/xmlschema/icmptype.xsd
/usr/lib/firewalld/xmlschema/ipset.xsd
/usr/lib/firewalld/xmlschema/service.xsd
/usr/lib/firewalld/xmlschema/zone.xsd
/usr/lib/firewalld/zones/FedoraServer.xml
/usr/lib/firewalld/zones/FedoraWorkstation.xml
/usr/lib/firewalld/zones/block.xml
/usr/lib/firewalld/zones/dmz.xml
/usr/lib/firewalld/zones/drop.xml
/usr/lib/firewalld/zones/external.xml
/usr/lib/firewalld/zones/home.xml
/usr/lib/firewalld/zones/internal.xml
/usr/lib/firewalld/zones/public.xml
/usr/lib/firewalld/zones/trusted.xml
/usr/lib/firewalld/zones/work.xml
/usr/lib/systemd/system/firewalld.service
we could copy firewall-cmd to the host (under /usr/local) but for now, let's not copy it and require users to use atomic run for launching the command within the container itself.
sure, makes sense =)
EDIT: It seems like /usr/lib/firewalld files can be used directly from the container, I understood it wrong, will omit the sections earlier.
firewalld/Dockerfile
Outdated
| maintainer="Rui xin Bao <rubao@redhat.com>" \ | ||
| atomic.type="system" | ||
|
|
||
| RUN dnf install --setopt=tsflags=nodocs -y firewalld && \ |
There was a problem hiding this comment.
it seems that kmod need to be installed as well:
2017-11-27 07:49:21 WARNING: modinfo command is missing, not able to detect conntrack helpers.
Installing the kmod package, solved this problem for me
firewalld/config.json.template
Outdated
| "platform": { | ||
| "os": "linux", | ||
| "arch": "amd64" | ||
| }, |
There was a problem hiding this comment.
please drop the "platform" section as it is not used anymore in OCI
firewalld/config.json.template
Outdated
| }, | ||
| { | ||
| "type": "bind", | ||
| "source": "/etc/sysconfig/firewalld", |
There was a problem hiding this comment.
I saw this error in my log:
Failed to open temporary file: [Errno 30] Read-only file system: '/etc/sysconfig/network-scripts/ifcfg-ens3.xz8ngeo7'
I think we should bind mount the entire /etc/sysconfig
| ] | ||
| }, | ||
| { | ||
| "type": "bind", |
There was a problem hiding this comment.
we don't need to bind mount /dev/log as we are already bind mounting /dev
There was a problem hiding this comment.
ah, yup, I copied this from net-snmp config.json.template file :p, will drop it then :).
firewalld/config.json.template
Outdated
| ] | ||
| }, | ||
| { | ||
| "destination": "/dev/pts", |
There was a problem hiding this comment.
we can probably drop this as well
firewalld/config.json.template
Outdated
| ] | ||
| }, | ||
| { | ||
| "destination": "/dev/shm", |
| "rbind", | ||
| "rw", | ||
| "mode=755" | ||
| ] |
There was a problem hiding this comment.
does firewalld need to access anything under /home or /root?
There was a problem hiding this comment.
does firewalld need to access anything under /home or /root?
I am not aware of it, it is also copied parts from net-snmp's config.json.template. so, will remove it to check if it is necessary
|
@peterbaouoft doing good, keep it up 😄 |
|
Addressed most of the comments above. Now the service seem to run with active running on Atomic Host shown below: ( will add README.md sooner and likely tmr ) However, one problem remain is that, when I run systemctl stop firewalld, it shows me a failed status: I run a check to look for journal look, there is one suscipious line: and this is the link for entire log, any ideas why is that happening ? https://paste.fedoraproject.org/paste/49rl5Pgd4bxCV~y5n9bIjw. I am personally not familiar with firewalld. So, also wonders, other than the stopping failure, is the current behavior for firewalld behaving correctly? Thanks for your time =). |
|
could you try with Another thing I was wondering about, does firewalld load kernel modules? If yes, I think we should bind mount |
|
Thanks for the review/commenting =).
ah, good point, I think we do need it =), https://github.com/firewalld/firewalld/blob/master/src/firewall/functions.py#L336. we just bind as ro mount right? ( and rprivate in the options), because we do not want to modify it? EDIT The failure for dbus access error seems to be a flake... please disregard it for now =) |
|
a read-only rslave bind mount is fine, in case it is ever overriden on the host, we will get the changes. I've not seen the SELinux failure and the Could you try to temporarily disable selinux and see if it works? We can address the selinux issue later, for example you could try to set the SELinux label in the config.json.template file to something like "system_u:system_r:firewalld_t:s0" |
sure, I will try to find usages of rslave, and apply it to the config files =D.
... Now the KillMode=none solves the problem for me. i guess it was probably due to the internal errors I had some where earlier, sorry for my misunderstanding =(. But now the container seems to work =D, will try and test it a bit more, and going to complete the README.md. Thanks for the info and your time =D. |
Includes initial README.md file for guidelines
|
@peterbaouoft let me know when you are ready for others to test. I'll be happy to give it a go! |
|
@ashcrow, sure, I still have some doubts currently about some parts of the system containers, may want to confirm with gisueppe about those. After those doubts are cleared, I think this system container should be ready for test =). |
|
@peterbaouoft sounds good. And to reiterate, good work so far! Hope you're learning quite a bit 😁 |
|
Pushed a fixup ⬆️, and also a documentation for installation instructions. Now the system container seems no longer have the failed state when running There are also a few doubts that I came across while making this container. Hopefully those won't bother you too much =). Q1: It might be a doubt that is related to previously asked questions, but I still think I am a bit unsure about the concept.. The doubt is that what might be the purpose that we copy /etc/firewalld into the host? I noticed during the execution of firewalld, files in My Guess: we might want user to configure the /etc/firewalld themselves, that might be one of the reasons why we copy it to the host Q2: For my other testing machines that are not atomic host, some of them seems not including policy kit by default, leading to some "service not found" warnings during execution. If that is the case, do we want to worry about the case where polkit is not installed? Q3: Minor: I noticed that there are some empty folders left over when running atomic containers delete firewalld. I see we have projectatomic/atomic#1131 that address this problem, so do we still have empty folders left over when the patch is applied? ( sorry, can't run a easy check, it seemed hard to build and apply upstream atomic into Atomic Host). The output is as following: as you can see /etc/firewalld and its empty subdirectories are not deleted |
|
|
I am not sure how hard it would be to do optional dependency checking =), but willing to do so if needed. But currently this container is targeting for Atomic Host right? If so, we don't necessarily need to install the polkit as we already have polkit as base package in Atomic Host. ( we can just assume polkit is there :p) So my opinion is, we don't need to have this optional dependency( we can assume polkit is there on host) unless people outside atomic host wants it? WDYT @giuseppe
cool, lemme try that :p
thx, @ashcrow :-) |
|
I was suggesting about having the systemd dependency as optional, so that it is used only when polkit is available (i.e. |
ah oops, I misunderstood earlier. Sorry for my poor english. In this case, do we want Require= or Wants=, I think both should be ok since |
|
It is odd..... now when I install the container to a new (freshly) installed Atomic Host, it can't seem to find /usr/local/share's policy file via dbus any more =(. ( But then, if ... I uninstall the container, and reinstall back, it runs without a problem..(#facepalm). Then every reinstall after that seems ok.... Interesting... Need investigating/testing more to see if the behavior can always be reproduced. (Sorry for the delay so far...) |
|
@peterbaouoft no need to be sorry 😄 |
|
...After some painful debugging..., I have found two ways currently that a system container for firewalld could fail to start. But I am unaware if those causes will be the same. Both errors appear to happen consistently ( at least had three tries, hopefully it is not just only me =( ). For case 1, the reproducing step is too long, so did not have a log of it... 1: Fresh install firewalld on a freshly provisioned Atomic Host (i.e rpm-ostree install git, then follow instructions for installing it). The first 2: This one is reproducible without having a freshly installed Atomic Host. It only requires you having a "working" firewalld system container. The steps to reproduce are as follows: on a f27 atomic host, steps to do after seeing a failed firewalld service After that, the failure can be reproduced through the following commands: Any clues what could be the causes for the problem? I am not sure at all how to solve this atm.. Thanks in advance =). @giuseppe can you take a look when you have time? :-). EDIT: the dockerfile I tested is mostly similar to the current one, except that the base image is |
|
the selinux issue we were seeing is fixed by: Could you please verify if it works for you? Also, dbus must be reloaded before it considers the new configuration. I am fine if you just document this step. After the atomic install, the user needs to run "killall -SIGHUP dbus-daemon". Doesn't the same issue happen with the firewalld rpm? I don't see any special handling in the post scripts for it. |
looks like it is working \o/, now the second case(dbus) no longer fails out after the patch is applied. (On my testing machine)
ah a bit weird, the above worked without me trying the killall command, I will also document it later just in case =).
for rpm, I am not seeing this behavior. But since the patch kinda solves the problem for me, let's not worry about it then? EDIT: now it appears the fresh install problem also got fixed :D. here is the log if you are interested. |
|
@giuseppe , Seems like with the new patch applied, both failing cases before all passes as well =) This is the host applying atomic upstream changes, the firewalld container might be ready for other folks to test =). The service is passing. Tho, tbh, I am not too certain what will the expected firewalld functionality be, so if there is any functionality issues, please let me know :p. Also Note: currently only firewalld binary is shipped, (i.e no firewall-cmd or other related commands is there with it yet). |
|
@peterbaouoft I'll give it a shot and report back! |
|
Very close. I ended up hitting a missing directory and an SELinux issue. Here is how I found them ... InstallLook at issueInvestigateCreate dir and try againRun ausearch -lLater I remembered this comment about using a specific version of |
Ouch, and thanks for the feedback =), the missing directory is expected as that should be autogenerated by systemd with Tho, for selinux is a bit weird... it seems working on my side T_T. I might need more info to debug here, hopefully you won't mind =). Did you try The patch for restoring selinux label should be effective at installation time(copying files) to the host. So the steps what I usually do on a fresh installed Atomic Host for firewalld container is: Wondering do you also follow a similar path? @ashcrow. |
|
Following exactly the steps in the paste (installing packages, unlocking, overwriting atomic rather than running from source, killing dbus) did end up working. I'm not sure if it's due to an update in packages or if the source runs didn't work as expected. 👍 This probably is blocked on projectatomic/atomic#1143 at this point. |
|
Update: Now another problem arises for the container ( so many cases to consider about #facepalm): The log is as follows: ( this is after applying the selinux fix patch) I suspect one of the causes may be that applications do not tend to recognize the policy files copied |
|
if you don't find an answer, could you try asking on the polkit-devel mailing list? |
|
For a better understanding, I've tried to make the changes required into polkit. I've tried locally with the version of polkit from my branch and it solves the problem you are seeing. I changed the system container to copy the files under https://github.com/giuseppe/polkit/tree/polkit-alternative-actions-directory Let's see where the discussion goes, and I could cleanup the patch if needed. I am not sure it is an acceptable version yet since it changes the API. |
|
@peterbaouoft could you file a bugzilla for polkit to allow an alternative directory for reading these files? |
|
@peterbaouoft could you please followup with the polkit people so to enable this use case for system containers on Atomic? |
|
@giuseppe yea, I would like to. But colin is the maintainer for polkit right? I guess we can bring this up at standup or so? WDYT FTR: the issue refers to https://lists.freedesktop.org/archives/polkit-devel/2017-December/000566.html |
|
/cc @cgwalters What's your take on the above? |
|
gentle pin :-) |
|
For the record I'm not "the" maintainer of polkit; I've done some work on it in the past...I probably still have I imagine a patch to add I still feel like long term the syscontainers RPM path (or alternatively, a special rpm-ostree overlay model for syscontainer files) is going to be the biggest win as then syscontainers can be more equivalent to RPM in practical power. |
|
I had prepared a patch for polkit to use This solves the issue we were seeing. While I agree with you that the |
The original thought came from https://bugzilla.redhat.com/show_bug.cgi?id=1403331
The container is still work in progress. The docker file can be
compiled successfully. When running the command, the service will not error out.
However, the command will time out eventually (not executing properly). I have a
few thoughts for debugging, will take a while to figure it out.
Have it here first for some early feedback :). (will modify the commit
message once lifting the WIP )