Mandos on Fedora/RHEL

[Nathanael D. Noblet]

On 11/07/2013 10:07 AM, Björn Påhlsson wrote:
> 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.

Sort of. CentOS/RHEL EOL aren't EOL [1] for at least 7-10 years. So we 
would still need a non systemd version. The thing is with dracut they 
have some networking support (no wifi that I'm aware of) - however I 
would expect them to want the wifi support to be added to dracut and not 
come from mandos if you know what I mean. So a dracut wifi module and a 
dracut mandos module.

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

Yeah, no wifi. Though like I said dracut would probably prefer to handle 
that as its own plugin.

As for the networking code in mandos client I think with some of the 
changes below (like reading from a config) you could leave it in and the 
default fedora package would 'disable' it via config.

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

I agree. I wasn't aware it was using such a small dependency. Getting it 
working on Redhat based systems would be fantastic!

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

So all non Fedora but Redhat projects use dracut without systemd. Fedora 
with dracut uses systemd. The mandos client needs to have the same 
changes for either. The difference will all lie in the dracut install 
module. One will install a systemd service the other will install a 
dracut script to run the client. In both cases plugin-runner is not 
required as dracut basically is the plugin runner and has console and 
plymouth password request modules.

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

The reason I say compile time is so that a user can't mess anything up. 
With a compile time switch the dracut module, the mandos client and 
everything expects it in the same spot. Without it a user could follow 
any number of online guides putting things in different places and never 
getting it to work. As its a boot time system, I'd prefer that we can 
set this to one specific place and everything around it expects it all 
in one place. Granted its your project so I'll deal with whatever you 
decide.

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

I have no problem setting where they should be via compilation. To me 
this provides distros with the most flexibility. Fedora wants it one 
place, debian another, X,Y,Z can take it and put it somewhere else but 
the code path remains the same.

As it stands now the default mandos-keygen for example expects 
/etc/keys/mandos, there is no /etc/keys in fedora, there are also 
differences between fedora and redhat/centos systems. So having a 
compile time switch that sets a GCC define / Makefile for some paths 
lets the code remain the same but lets a distro decide where it should 
expect whatever it expects. This also helps with selinux integration.


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

Sounds good to me!


I wanted to try to make some of these changes in a bzr branch however I 
have no idea how bzr works so I wasn't sure how do it and then provide 
patches... It also seemed somewhat related to the whole 'compile time' 
values vs adding multiple directories to search.

>
> /Björn Påhlsson
>

[1] - https://access.redhat.com/site/support/policy/updates/errata/

-- 
Nathanael d. Noblet
t 403.875.4613