chroot inside LXC container?

[jayg30]

I spun up an LXC of CentOS7 and walked through the installation of packetfence (NAC). I got to the point on setup where it wants to connect to active directory and just haven't had any luck and I'm not even getting anything useful in logs. So I started researching a bit and found THIS.

As you can see the domain join process creates chroot directories.
Those are required to be able to join multiple AD domains separately because there is no way to configure winbindd to listen to a different (unix) socket.

Which lead me to wonder, could my issue be that my LXC running on proxmox is also trying to run something in a chroot? I'm not well versed on LXC and figured someone else might have more insight so I don't keep chasing my tail.

 

[oguz]

Chroot should work in the container (the chroot command that is).

It might be a problem if it's another container though (systemd-nspawn, docker & co). In that case, enabling "Nesting" in the Container Features should solve the problems.

I don't know much about packetfence, but while I was reading through the installation guide, I also saw this:

Regarding SELinux or AppArmor, even if they may be wanted by some organizations, PacketFence will not work properly if SELinux or AppArmor are enabled

We use AppArmor on the LXC containers by default, but IDK what they exactly do in this software that causes problems with AppArmor, so keep that in mind. You can disable AppArmor (at your own risk) if that causes problems as well.

 

[jayg30]

Chroot should work in the container (the chroot command that is).

It might be a problem if it's another container though (systemd-nspawn, docker & co). In that case, enabling "Nesting" in the Container Features should solve the problems.

I don't know much about packetfence, but while I was reading through the installation guide, I also saw this:



We use AppArmor on the LXC containers by default, but IDK what they exactly do in this software that causes problems with AppArmor, so keep that in mind. You can disable AppArmor (at your own risk) if that causes problems as well.

Thanks.
I just realized I didn't disable AppArmor. For some reason I just checked if selinux was disabled inside the container. So I've added;

features: nesting=1
lxc.apparmor.profile = unconfined

to /etc/pve/lxc/[id].conf. This is just for testing anyway so not to concerned. Will see if that helps. If not I'll go ahead and try spinning it up in KVM to test. It might just be a problem with the packetfence configuration.


Packetfence is a NAC (network access control). It's 802.1x/Radius stuff. It leverages the opensource software freeradius extensively, as well others like apache, netdata, mariadb, redis, etc. The jist is it provides Authentication, authorization, and accounting (AAA) to devices/users on a network. It does stuff like dynamic VLAN assignment, DHCP fingerprinting etc. Overview HERE. An alternative to proprietary tools like Aruba Clearpass, Cisco ISE, ForeScout, Microsoft NAC, etc. Pretty complex software, super powerful. I'm not sure if the issue with SeLinux/AppArmor is a technical one. I think it might just be the devs don't fully understand it and their expertise is in other areas. The software is rather niche (enterprise) to begin with so probably doesn't get the same level of dev attention. It's 1 of 2 opensource NAC packages I know of, and the other is relatively new.

 

[guletz]

Hi,

Maybe for you it could be easier to use in a VM a Mikrotik CHR with usermanager and/or captive portal. I can guess that in 2-3 hours you can be up and ready.

 

[jayg30]

Hi,

Maybe for you it could be easier to use in a VM a Mikrotik CHR with usermanager and/or captive portal. I can guess that in 2-3 hours you can be up and ready.

Not the same type of software, not a NAC. Packetfence is much more then a captive portal and guest access.

I installed as a KVM VM and it worked. I'll go back and test as a container later. I think I might have not disabled the firewall.