Re: a note on order of arguements to systemctl command
On 08/25/2010 01:39 AM, pbrobin...@gmail.com wrote: > I'm still trying to work out how to get systemctl to boot > my netbook into run level 5. The usual way of changing this > seems to have no effect and that is a problem. There's a new question/answer just added to the systemd FAQ that explains this: Q: How do I change the default runlevel to boot into? A: The symlink /etc/systemd/system/default.target controls where we boot into by default. Link it to the target unit of your choice. For example, like this: # ln -sf /lib/systemd/systemd/multi-user.target /etc/systemd/system/default.target or # ln -sf /lib/systemd/systemd/graphical.target /etc/systemd/system/default.target ==== -- David Smith dsm...@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Secure boot and packaging third-party kernel modules
On 05/28/2015 10:26 AM, David Sommerseth wrote: ... stuff deleted ... > Any thoughts or comments to this approach? Anyone got a better idea? Your process looks reasonable. > Yes, I do know it is not good to have the keying material for the > signing too easily available. So I'm also keen to hear ideas how to > protect the key better. With that said, I'm planning on only providing > access to the key file to the root user only. And I'll look into if I > can restrict the accesss even further with some SELinux rules (so only > the ExecStartPre= script can access it together with the "preparation" > script. Systemtap has a similar problem. By definition, we compile kernel modules and still need to work on a secure boot system. To solve it, we automated the process you outlined above and added it to our existing "compile server" functionality. On a client machine you ask for a systemtap script to run, and behind the scenes the script gets shipped off to a compile server that has a matching kernel devel environment and matching MOKs. The signed module gets shipped back to the client system and run. The advantage we have here is that if you have lots of client systems, none of them have the private MOK key installed on them - only the server has the private key(s). We only pass around public key fingerprints. > Another thought ... Are there other packages who could benefit of such a > solution if it was made more generic? I'm willing to investigate into > this too, if there are more users out there ... Or if someone has > already done that - no need to reinvent the wheel! Systemtap's solution is probably pretty specific to ourselves, but the general idea (and perhaps some code) could certainly be borrowed. But really the best solution here is to get the mhvtl kernel module upstream. -- David Smith dsm...@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: packages which require the kernel package
On 03/10/2014 02:22 PM, Matthew Miller wrote: > When Fedora is in a container (a la Docker), the kernel comes > from the host, not the installed package set. I noticed a number of packages > which actually have a requirement on the kernel package. This isn't very > helpful, since the installed package says nothing about the running one, and > forcing the package doesn't help. > > For many of these, the requirement is actually that the running kernel have > a certain feature, and the hope is that the package version check will do > it. For others, like ipset, I'm not quite sure -- there's a spec file > comment that says "This is developed hand in hand with a kernel module", but > it then just says "Requires: kernel". > > I think quemu-sanity-check may be the only one that actually really wants a > kernel. Possibly libguestfs too -- I didn't dig too deepy. > > There aren't actually a lot: ... > systemtap-devel / systemtap-runtime (from systemtap) I've checked in a change to systemtap's upstream spec file that should fix this. It should be present for the next rawhide build on Monday. <https://www.sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=92319a32b14defa5c6344314d3a88a1cf2baff71> -- David Smith dsm...@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Enabling "-Werror=format-security" by default
On 11/20/2013 10:51 AM, Dhiru Kholia wrote: > On 11/20/13 at 09:27pm, Dhiru Kholia wrote: >> We are working on a proposal to enable "-Werror=format-security" >> compilation flag for all packages in Fedora. >> >> Currently, around 400 packages FTBFS if this flag is enabled. > > A list of packages which FTBFS is available at, > > http://people.fedoraproject.org/~halfie/rebuild-logs.txt Looking at the list, I see several (~17) packages with errors of the form: error: -Wformat-security ignored without -Wformat [-Werror=format-security] Which is an error, but not exactly what you are trying to catch. Got any ideas on what is going on here? -- David Smith dsm...@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
