Mandos on Fedora/RHEL

[Nathanael D. Noblet]

On 11/05/2013 02:26 PM, Teddy Hogeborn wrote:
> Nathanael Noblet <nathanael at gnat.ca> writes:
>
>> So in fedora/rhel/centos land the plugin runner is unnecessary. Dracut
>> already has console and Plymouth ask password commands. The little
>> systemd service I 'created' is run in tandem with all other relevant
>> password retrieval pieces. The network pieces are handled by other
>> dracut modules and can deal with bonded interfaces VPN etc..
>
> Huh, I do not recall dracut being this advanced last I checked, but this
> was some time ago.  Do you know if this behavior occurs both with and
> without systemd?

So this advanced feature is part of systemd.

http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/

Granted dracut without systemd doesn't have the password agents it still 
has all the network functionality I think it needs to handle the 
interfaces. It also has a number of ways to ask for passwords.


>> Given that how would you prefer to proceed? I'm wondering if the
>> actual client portion could be split out into a separate little
>> program. So all the avahi setup and anything needed to setup networks
>> in its own area. Then a network client that requires the keys and IP
>> and port and does its thing. In fedora and derivatives we simply
>> install that little client and the systems services. In Debian and
>> derivatives you include the entire plugin runner? Thoughts?
>
> The Avahi setup in mandos-client is necessary in the normal use case; it
> is how the client finds Mandos servers using ZeroConf, and it is not
> called at all when using --connect.  We want to keep the usage of
> ZeroConf to be the default, since this is the most easy way to set the
> whole system up; just start a Mandos server on the same network, add the
> client info to it and it all just works.

So in my case Avahi is completely useless. I would love in fact to be 
able to provide a avahi enabled and avahi disabled client. In my 
particular case we have a small number of servers in different locations 
and so avahi is completely useless for me. I can see that it could be 
useful for others so I'm not saying it shouldn't be there. Plus I can 
imagine some people complaining about initramfs size. So allowing them 
to choose avahi vs non-avahi.

> Also, a split is unneccessary; just specify --interfaces=none to
> mandos-client, and it will not do *anything* to any interfaces and
> simply use any interfaces that are already available and configured.
>
> Do you have any other reasons for wanting a split?

Well my main reason for a split is for flexibility and so I can feel 
like integrating it with Fedora/CentOS/dracut feels less like a hack if 
you know what I mean.

So here's how it works with dracut+systemd

A service is created that can answer requests for passwords. This 
service is currently set to call /usr/bin/mandos-client. The dracut 
module that installs this service can install any other scripts / 
programs it wants. For example one of the things it installs in my case 
is a parse-mandos.sh script that reads the kernel cmdline to read dracut 
options. (rd.mandos.server for example to specify what server to connect 
to)... It can create udev rules or basically do anything it needs to.

The issue is its difficult to pass the mandos client any parameters. If 
it could read a parameter file I'd be set. Otherwise I have to modify it 
to read environment variables or modify the mandos ask-password-agent to 
read some variables and change how it calls mandos-client.

It would be super easy in the dracut way of doing things to have a 
mandos-client.conf file that has the necessary settings and the client 
read it by default. That allows the admin to configure it and update the 
initramfs or have some settings changed via the grub boot line.

So all that to basically say there doesn't *have* to be a split.

However one improvement would definitely be a way to set where 
everything is expected. For example there is no /conf/conf.d/mandos 
directory in the initramfs. It would be great to be able to set compile 
time options for most of that. Or have that all read from the same config.

If the mandos sources were simply re-organized a bit I imagine it would 
be easy to do what I'm thinking. Something like having the necessary 
parts for the start_mandos_communication in its own source file. Then 
two more source files one with avahi one without. Both use the object 
file from start_mandos_comm to do the actual config.

>> For my test today I'm going to modify the mandos client to grab some
>> variables from the environment. I'm still using non avahi connection
>> methods. I noticed that the code has a comment about that code path
>> being for testing purposes. I'm wondering why? I have a handful of
>> servers but most are in separate data centers so avahi is useless to
>> me if I'm not mistaken..
>
> Well, that particular code was initially written for our own testing
> purposes; we did not envision the scenario of remote Mandos servers to
> be common.  But the code path is supported; from the top of my head I
> would say that the comment "(Mainly meant for debugging)" is reflecting
> our expected use case, and not indicative of the level of support for
> the code.
>
> /Teddy Hogeborn
>
>
>
> _______________________________________________
> Mandos-Dev mailing list
> Mandos-Dev at recompile.se
> https://mail.recompile.se/cgi-bin/mailman/listinfo/mandos-dev
>


-- 
Nathanael d. Noblet
t 403.875.4613