Mandos on Fedora/RHEL

[Björn Påhlsson]

On 11/06/2013 06:07 PM, Nathanael D. Noblet wrote:
> > 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/

Password Agents is nice new feature, and looks identical to the
plugin-runner but agnostic to the type of querier. Less code for us to
maintain, and more stable way to do things.

The splashy and usplash plugins would have to reimplemented or removed
(Could be deprecated given the age of those).

As such, this looks like a good way forward (and future proof) to
write a mandos password agent and use plugin-runner as a legacy
support for non-systemd system s.

> 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.

Since the Mandos network functionality is compatible with already
brought up network interfaces, it seems a bit unnecessary to try to
break out that part of the code. As long as the Dracut network module is
optional, mandos-client would also have to depend on that module.

There are some open questions I have yet to research regarding the
Dracut network module. Does it support wireless networking setup? The
https://fedoraproject.org/wiki/Dracut/Options#Network documentation
does not seem to say so at this moment.

> 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.

As size goes, we are not using everything of Avahi project, but rather
only the subset included in the avahi-core package, which was designed
to be used primarily in embedded platforms. This was a conscious
choice to minimize the added size to initramfs. Note: the Avahi daemon
is not present.

That said, it should not be that hard to implemented a build argument
for --no-avahi, but I personally consider that a secondary priority to
create a inital release package for Red Hat.

> 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.

With systemd and the password agent, mandos-client could use a config
file since plugin-runner.conf would no longer exist. That in turn
could then configure the service file, like adding --connect
server_address to the command line.

How common is a non-systemd setup for Redhat? It would be preferable not
having one solution for current initramfs-tools without systemd, one for
dracut without systemd, and one for systemd that can be shared with
initramfs-tools and dracut.  Since systemd looks to be the future, it
would be better to simply develop towards that, and let the
initramfs-tools without systemd be deprecated in time.

> 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.

The /conf/conf.d/mandos is simply the directory which the
initramfs-tools made available, and at the time Mandos was written, it
was the only option available.  We could certainly use a built-in list
of directories to search for our files in.  A compile-time option, on
the other hand, introduces risk via the complication factor; suddenly
there would be many possible behaviors of the binary depending on
compilation options.  It is simpler to auto-detect on runtime.

As I see it, the systemd mandos-agent can have in its service file all
the appropriate command line switches for mandos-client; this service
file will then serve as a config file.  If desired, this service file
could be generated at initramfs creation time based on a simpler config
file in, say, /etc/mandos/mandos-client.conf.

(We do need a configuration directory, since we need somewhere to
store the key files.  I assume these should not be compiled into the
binary.)

> 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.

Using mandos-client without using ZeroConf is easy; just use the
--connect option.  If it's the size of the Avahi daemon you're worried
about, then let me reassure you, mandos-client uses only the
*avahi-core* library.  It is *not* dragging in the whole Avahi daemon
and the assorted avahi libraries. The library used by mandos-client is
221K for an x86-64 system.  This is not, to me, a size significant
enough to warrant a split, especially not when considering that the use
of ZeroConf is what we view as the primary use case.  A single binary to
cover all use cases is simpler, especially now when we already will need
one additional binary (mandos-agent).

/Björn Påhlsson

-- 
The Mandos Project
http://www.recompile.se/mandos