On Aug 15, 2014, at 17:46 , Pat Riehecky wrote:

> On 08/12/2014 10:53 AM, Stephan Wiesand wrote:
>> On 2014-08-11, at 21:49, Pat Riehecky <[log in to unmask]> wrote:
>> 
>>> On 07/30/2014 10:57 AM, Stephan Wiesand wrote:
>>>> On 2014-07-30, at 17:40, Stephan Wiesand <[log in to unmask]> wrote:
>>>> 
>>>>> On 2014-07-29, at 17:44, Pat Riehecky <[log in to unmask]> wrote:
>>>>> 
>>>>>> On 07/29/2014 09:53 AM, Stephan Wiesand wrote:
>>>>>>> On Jul 25, 2014, at 19:04 , Pat Riehecky wrote:
>>>>>>> 
>>>>>>>> For secure boot kmods, it looks like there may be some odd work to be done....
>>>>>>> Thanks for the hint. I hadn't thought of that yet. Sure, our modules should be signed. I believe this has potential benefits even without UEFI or secure boot.
>>>>>>> 
>>>>>>>> I was pointed here for an example:
>>>>>>>> 
>>>>>>>> https://messinet.com/rpms/browser/dahdi-linux-kmod/dahdi-linux-kmod.spec
>>>>>>> I didn't find that resource particularly helpful. But upstream documentation suggests it's fairly trivial: According to the "signing kernel modules for secure boot" section of the system administrators guide, all it takes is this:
>>>>>>> 
>>>>>>> perl /usr/src/kernels/%{kernel}/scripts/sign-file \
>>>>>>>  sha256 \
>>>>>>>  SL_signing_key.priv \
>>>>>>>  SL_signing_key_pub.der \
>>>>>>>  openafs.ko
>>>>>>> 
>>>>>>> The only question is where to find the keys. And, academically, why do they need the public key for creating the signature?
>>>>>>> 
>>>>>>> A first proposal: If the build is initiated with "rpmbuild ... --define 'module_key /path/to/SL_key.priv', the spec will attempt to sign the modules with that private key and the corresponding /path/to/SL_key_pub.der as the public key. If module_key is not defined, the modules won't be signed.
>>>>>>> 
>>>>>>> Obviously, this proposal could be adapted to whatever scheme you have decided on for naming your key files, or we could have separate %defines for the two files.
>>>>>>> 
>>>>>>> - Stephan
>>>>>>> 
>>>>>> Our exact secure boot process is still evolving a bit as we wait for our hard token.
>>>>> Ok.
>>>>> 
>>>>>> The folks over at ELRepo (thanks Phil Perry, Akemi Yagi, and Alan Bartlett) emailed me their kmod template for EL7.  I've attached it here as a useful resource in the whole conversation.
>>>>>> 
>>>>>> My main worry is stripping debuginfo breaking the signature. Typically the strip is run after %install which gives us some 'issues'.
>>>>>> 
>>>>>> The dahdi spec has one workaround (lines 61-107), but it is huge and somewhat messy looking
>>>>>> The ELRepo spec is clean and simple yet seems a bit more aggressive (lines 28; 51-52), it leaves us without debuginfo
>>>>> I'm currently leaning towards borrowing from both dahdi and ELRepo. Much of the dahdi hack is already present in our spec, so I propose we use that and wrap it into the switches and macros as used by ELRepo or at least very similar.
>>>>> 
>>>>>> /usr/lib/rpm/find-debuginfo.sh only strips executable files.
>>>>> My next preference would indeed be not to strip the kernel modules (I believe this doesn't even waste kernel memory, but I could be wrong) and have no debuginfo package for the kmod.
>>>>> 
>>>>>> As for macros:
>>>>>> I'd love to keep the macros compatible with pesign's expectations mostly to keep things simple on the build host.
>>>>> What are pesigns expectations?
>>>>> 
>>>>>> It might be nice if the kmod was signed with a dummy key in the event of 'no key found'.  I believe the kernel does that.  It doesn't really provide any additional assurances, but it may make the spec easier to maintain and test on arbitrary systems.
>>>>> Creating dummy keys during build may starve due to lack of entropy, but I'll think about it.
>>>>> 
>>>>>> Beyond that, I think I'll have to punt to Connie as she is heading up or Secure Boot stuff.  If I'm off base ignore me.
>>>>> Sure :-) Seriously though, thanks for pointing out where the devil is.
>>>> And I have a preliminary 1.6.9 srpm here:
>>>> 
>>>> https://claus.ifh.de/owncloud/public.php?service=files&t=d4c59fd89f6ad41418f189c6e9ad4696
>>>> 
>>>> It implements most of what was discussed, except for the module signing stuff. I hope to get around to that tomorrow.
>>>> 
>>>> The srpm should still work on SL5/6 too and the behaviour unchanged there. On SL7, it should clean up /sbin usage, builds packages with a basename of openafs-1.6-sl (can be overridden at build time, and changing it to openafs16 is a one-liner), and uses systemd unit files.
>>>> 
>>>> I have the client running on an SL7 test system, but I'd be surprised if there weren't bugs left all over the place. In particular the systemd stuff may well be less than perfect. Just wanted to give you a chance to look at what I have as early as possible.
>>>> 
>>>> Stephan
>>>> 
>>> Hey Stephan,
>> Hi Pat,
>> 
>>> I've been chasing down odds and ends, sorry for the delay.  Connie is still our Secure Boot Czar so I've not really chased that down, but for the package/systemd side of things stuff looks fairly viable.
>> I've been pretty busy with other stuff too. No problem.
>> 
>>> I've a few small change requests:
>>> 
>>> I attached a patch with three fairly minor alterations - two of which are in spec file comments
>> Those are fine.
>> 
>>> I'm wondering if packages that have %{nsfx} defined should have a Provides: on the non nsfx name for ease of yum/kickstart naming.  If I don't care between 1.6 or <otherversion> it might be nice if 'yum install openafs-client' just worked.  Thoughts?
>> I think this defeats one of the points for the rename: Now it becomes ambiguous again what yum pulls in when you type that and have more than one repo enabled which provides the packages. It may even make it fail by trying to mix, say, ELrepo and SL packages again. IMO we can then stay with plain "openafs", and just keep the %{nsfx} stuff around for eventual use with OpenAFS 1.8.
>> 
>> Thoughts anyone?
>> 
>>> I'm wondering if the '.generated' suffix can be removed from the /etc/sysconfig/ files?
>> We obviously can't have the file admins are supposed to edit and the one really generated from that have the same name. And I'd like to keep both in /etc/sysconfig to avoid potential SELinux and other troubles. If the suffix makes your eyes bleed, how about prepending a "." to the generated files?
>> 
>> It's just the only solution I found for keeping the functionality of the init scripts (except for "service afs purgecache"). Alternatively, we can dumb things down to what systemd foresees.
> 
> 
> I usually conceive of things in /etc/sysconfig/ as user editable.

There have been files in there ~forever with headers like this one:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.

> I'll confess I didn't check the spec file on this before now and I now see that /etc/sysconfig/afs.generated is not tagged as a config.

It's rebuilt every time the client starts.

> Now that I see a bit more of what is going on, let me double check my understanding:
> 
> afs.generated is built out of /etc/sysconfig/afs via /sbin/openafs-client-init.sh prepare and then the afs client service imports afs.generated into its environment.

Right. Where openafs-client-init.sh is just the init script that would be used on SL5/6. Compared to what we're using today, it only has a "prepare" action added to write out the results from the internal logic to the environment file for the service unit rather than using it itself.

The objectives here were to have a single place to maintain the code doing those handy things, but still make use of systemd's features, while the user/admin maintains the same configuration file in the same way as on SL3. This may be overly ambitious...

> If my understanding is right on this, I would expect the resulting environment file probably belongs under /run/afs/ as it is built automatically and does not need to persist across restarts of the process.
> 
> A mkdir -p /run/afs results in a context of unconfined_u:object_r:var_run_t which I'd expect it can read without too much worry.
> Or you could stash the generated file in the cache dir, that should remain accessible.
> Or you could pre-append a . to hide it from a normal ls.

I'd prefer that last option, since it's known to work. To be honest, I don't [want to] know in which security context the ExecStartPre actions are actually run (hopefully not systemd's, and hopefully not the same as you running the mkdir as root in unconfined_t either), and this was/is the choice with the least potential for surprise.

> It may be worth providing a blank /etc/sysconfig/afs with some comments explaining how all the machinery works for this

The default /etc/sysconfig/afs being identical for SL5, SL6 and SL7 is one of the main reasons why I did it this way (and is long enough as it is). The %changelog should have some information on how this all works, but providing a readme is certainly a good idea. Don't hold your breath though.

> Long term, becoming a 'dumb' systemd service would be nice, but that init script does so much that seems very handy...... and I've not got a lot of background in administration of AFS.

I'm a huge fan of "k.i.s.s.". But I'm also a huge fan of backward compatibility (which is also very much like both AFS and EL), and I like the fact that our packages make it outright trivial to set up an AFS client in many common environments.

I/my site can cope with going dumb, no problem. Chances are EL7 will live for ten years at least. So if that's what we want, we should probably do it now.

>>> For the systemd --scripts at the end, I noticed you'd coded the behaviour.  Any reason against the systemd provided macros: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
>>> 
>>> As a general comment on the systemd unit activation, I'd lean towards using 'preset' rather than 'enable' and tossing the necessary stanzas to enable in %{_prefix}/lib/systemd/system-preset/70-afs-<pkg>.preset  .  I think it may make some kinds of administration easier for people down the line.
>> Fine, I like that better too. Simply didn't know about it.
>> 
>>> This is probably my ignorance of AFS (which is a lot), but the openafs-1.6-sl-krb5 package was not required by openafs-1.6-sl-client. That seemed odd to me.  If I'm off base here, don't worry about it; not having aklog was 'unexpected' but easily solved.
>> It really isn't required. The client is fully functional without krb5 if you use the old kaserver (a slightly modified krb4 implementation).
>> 
>>> The packages built up fine and seem to work with FNAL's AFS.
>> Thanks a lot for looking closely at them!
>> 
>> 	Stephan
>> 

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany