Dracut + Disk Crypt Passphrase Timeout
I haven't used the disk encryption features much so maybe this is normal, but what I saw seemed odd enough I thought I better post it here. I have just installed F18 (with RC1) and configured the disk crypt feature. I just did my first boot, saw the prompt for the passphrase come up when I got called off to tend to problems elsewhere. Upon returning I noticed that my system was now in a dracut emergency recovery shell. I saw some message about a timeout, but had already hit C-A-D before taking good mental notes. Is this timeout normal and expected or is it a bug? (I'm not worried about it, but thought someone might like to know if it's unexpected.) -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: update some testcases
From: Adam Williamson awill...@redhat.com Sure, but then you've just switched modes. The decisions you made on the Guided path are wiped out. This could be made clearer in the UI, though - I've seen several users report that they expected to be able to, say, delete partitions in Guided mode, then create them in Custom mode. I did that just today with my desktop machine. I wanted to leverage the Guided feature for most of the setup, but needed to rm the home partition since I have that via NFS. To me the existing naming seemed fairly clear. In a Guided mode, I expect to have the way led for me, but I should be allowed to deviate. With a Manual mode I expect to lead the way, but also be offered tools to make that easier. I guess I didn't think of it so much as modes though, as much of a initial question of how much assistance was I going to require. PS. I may have all the names horfed up here. I've only used the new anaconda this once. I've installed F18 hundreds of times already, but always via kickstarts ala livecd-tools. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd: Failed to initialize SELinux context: Permission denied
Daniel J Walsh dwa...@redhat.com wrote on 12/07/2012 10:46:11: On 12/07/2012 08:44 AM, Bruno Wolff III wrote: On Fri, Dec 07, 2012 at 08:22:10 -0500, john.flor...@dart.biz wrote: Thinking selinux might be preventing the relabel from happening (?!?) I rebooted with selinux=0 so that I could reconfig /etc/sysconfig/selinux having SELINUX=permissive, touched /.autorelabel and rebooted again. This time I saw the relabel process do its thing and trigger a reboot. I then went back to reconfig /etc/sysconfig/selinux having SELINUX=enforcing, rebooted and all seemed well, finally. The autorelabel is supposed to happen early in the boot process and I think it is supposed to work even if you system normally comes up in enforcing mode. So that sounds like a bug. (You can come up in permissive mode using the enforcing=0 kernel parameter. This is a bit more convenient in some cases for a one time boot, than changing the selinux configuration.) This is generally the safeest way to relabel as you don't want processes that started with the wrong context creating more incorrectly labelled files while you are trying to fix things up (with say restorecon). So, I'm all good now, but there may be some bugs in that relabel should happen automatically bit. -- John Florian Yes systemd is supposed to set the machine into permissive mode for the relabel, but I guess if the machine is totally mislabeled, systemd might be prevented from doing this, although I would figure systemd would be running as the kernel label. Bottom line this would be difficult to diagnose what happened to force you to relabel in permissive mode. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDCD0MACgkQrlYvE4MpobN0gACeIRh+3rBTIXX/GVvxxIrMnvUq 1EUAoNfsFpd+zYOiPq9h/+fXol6j3mLO =kYu4 -END PGP SIGNATURE- I agree this would be hard to diagnose. I doubt I could reproduce the situation given all this poor system has been through. That and I'm already up to my ears in alligators trying to port our software stack over to what's becoming F18. As I stated, it's no longer a problem for me, so I'm happy. I just wanted to make sure those who would want to know had been informed. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd: Failed to initialize SELinux context: Permission denied
Daniel J Walsh dwa...@redhat.com wrote on 12/07/2012 14:40:55: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2012 11:26 AM, john.flor...@dart.biz wrote: Daniel J Walsh dwa...@redhat.com wrote on 12/07/2012 10:46:11: On 12/07/2012 08:44 AM, Bruno Wolff III wrote: On Fri, Dec 07, 2012 at 08:22:10 -0500, john.flor...@dart.biz wrote: Thinking selinux might be preventing the relabel from happening (?!?) I rebooted with selinux=0 so that I could reconfig /etc/sysconfig/selinux having SELINUX=permissive, touched /.autorelabel and rebooted again. This time I saw the relabel process do its thing and trigger a reboot. I then went back to reconfig /etc/sysconfig/selinux having SELINUX=enforcing, rebooted and all seemed well, finally. The autorelabel is supposed to happen early in the boot process and I think it is supposed to work even if you system normally comes up in enforcing mode. So that sounds like a bug. (You can come up in permissive mode using the enforcing=0 kernel parameter. This is a bit more convenient in some cases for a one time boot, than changing the selinux configuration.) This is generally the safeest way to relabel as you don't want processes that started with the wrong context creating more incorrectly labelled files while you are trying to fix things up (with say restorecon). So, I'm all good now, but there may be some bugs in that relabel should happen automatically bit. -- John Florian Yes systemd is supposed to set the machine into permissive mode for the relabel, but I guess if the machine is totally mislabeled, systemd might be prevented from doing this, although I would figure systemd would be running as the kernel label. Bottom line this would be difficult to diagnose what happened to force you to relabel in permissive mode. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDCD0MACgkQrlYvE4MpobN0gACeIRh+3rBTIXX/GVvxxIrMnvUq 1EUAoNfsFpd+zYOiPq9h/+fXol6j3mLO =kYu4 -END PGP SIGNATURE- I agree this would be hard to diagnose. I doubt I could reproduce the situation given all this poor system has been through. That and I'm already up to my ears in alligators trying to port our software stack over to what's becoming F18. As I stated, it's no longer a problem for me, so I'm happy. I just wanted to make sure those who would want to know had been informed. -- John Florian If you have a selinux-policy version of 57,58,59 it could have also failed on the relabel in enforcing mode, since there was a major bug in policy that should be fixed by -60. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDCRkYACgkQrlYvE4MpobNVEwCg3sx2OlPipwq2YHlS+fxsozCb ayUAn2r56PioTL8Swc0nG9cglnpOT3tY =Bds9 -END PGP SIGNATURE- Believe it or not, I had enough ssh history in konsole on that machine to scroll back and see where I was doing the upgrade and lo and behold, it was on -59 at the time. Would it make sense to capture the policy version in the audit.log alongside those AVCs? Seems like that would be helpful when reviewing them. Or would it be useless without some sort of tainted flag like the kernel uses to indicate when the policy had been augmented in some way? -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
systemd: Failed to initialize SELinux context: Permission denied
As one bitten by https://bugzilla.redhat.com/show_bug.cgi?id=858373 I was hoping to set SELinux back to enforcing on my F18 test box in order to provide feedback for https://admin.fedoraproject.org/updates/FEDORA-2012-19802/livecd-tools-18.13-1.fc18 . I've had SEL disabled for quite awhile on this box now because building images with livecd-creator was more important. Seeing that an update was available, I changed /etc/sysconfig/selinux for enforcing and rebooted and was promptly greeted with the message show in the subject. The box just hangs there at this message. I wasn't expecting this behavior -- figured livecd-creator would be as before or better. I guess for now I need to boot with selinux=0 unless someone has any suggestions for this problem. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: new criterion proposal: core kickstart commands
From: Kamil Paral kpa...@redhat.com In the discussion about https://bugzilla.redhat.com/show_bug.cgi?id=869978 we agreed that we should have a list of core kickstart commands that should definitely work for a Final release. All the options are documented here: http://fedoraproject.org/wiki/Anaconda/Kickstart I tried to make a core selection. I had the following in mind: 1. Kickstarts are used for automation, therefore the most important commands related to automation must work (manual intervention is not fine). 2. Commands which are easily work-aroundable shouldn't be part of the core selection. Example: 'authconfig' kickstart command is just a wrapper around authconfig tool. You can issue the same command in %post and it should do the same. If %post works, it's trivial to work around nonfunctional authconfig kickstart command. The same applies for 'firewall', 'group', 'user' and others, it's trivial to run it in %post. 3. Some commands have plenty of options. We can't really define into the smallest detail which one of them must work and which doesn't have to. In this case a blocker-bug discussion is necessary to weight the importance of the option, its usage volume and the risk involved. I arrived at three different categories of the core set: == Setting up installation environment == network updates keyboard lang rootpw * 'network' and 'updates' are core commands, in same cases you really need them to start the installation. * 'keyboard' and 'lang' might probably be worked around in %pre, but it might be non-trivial for people. But I'm not firmly decided here. * 'rootpw' can be worked around in %post, but I consider it pretty basic command to work without problems == Partitioning the system == zerombr autopart clearpart part bootloader volgroup logvol * Partitioning is pretty major function of the installer and if doesn't work, it's just useless. I consider it core. * LVM support might be questioned. I decided to put it here, because LVM is the Fedora default and it might be pretty useful in some automated installation. We can discuss it though. * I haven't included some other partitioning commands, like 'btrfs', 'raid', or 'multipath'. They are useful and pretty, but I don't see them as really core. == Installation process == install upgrade repo %packages %pre %post poweroff reboot * 'install' and 'upgrade', because you need to be able to tell installer which mode to use * 'repo' because you need to set your mirror, or activate/deactive updates-testing, or something like that * '%packages' because package selection is one the core functions ofkickstart * '%pre' and '%post' because it is often needed for some post- install setups (setting up sshd, creating accounts etc) and also can be used to work around broken commands * 'poweroff' and 'reboot' because in an automated environment these might be very important for you. Rebooting a computer that is 1000 miles away from you might not be an easy task. It might be a bit difficult to put this into criteria, I think there is no other way except than list the core commands. We can't say everything related to partitioning, because then people would argue btrfs command is included. Maybe we can create a separate page/subpage related to kickstart core commands and just link to it from the criteria document. Comments very welcome. I make heavy use of the %include directive which I don't see that you've mentioned anywhere. It's a rather fundamental feature for how I use kickstarts through livecd-tools to effect dynamic sections. I suppose I could revise my tools to create a dynamic, yet monolith kickstart script, but at present I have everything tooled to around a core kickstart script, numerous static helpers that get %included and several dynamic helpers that are also %included. Thus I'd appreciate seeing %include added to the criteria, if it's not too much of a pain. FWIW it's presently working fine for me with my test box that was F17 originally and yum-upgraded to F18 shortly after the branch was made. This box is running my tool that runs livecd-tools to make custom live spins that I've been heavily testing and developing since the branch. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Heads up: Fedora 18 Final Change Deadline and Feature Process changes
From: Jaroslav Reznik jrez...@redhat.com To: devel-annou...@lists.fedoraproject.org, test- annou...@lists.fedoraproject.org Date: 12/05/2012 15:53 Subject: [Test-Announce] Heads up: Fedora 18 Final Change Deadline and Feature Process changes Sent by: test-boun...@lists.fedoraproject.org Hi! FESCo on today's meeting decided to move the final change deadline by one week earlier (2012-12-11) to avoid Christmas holidays break [1] but the final release date remains the same - 2013-01-08 [2]. After the Final Change Deadline only approved blocker and NTH bugs will be included into the final release, please make sure to do the Bodhi work for everything you'd like to see in final. FESCo also agreed on Feature Process modifications [3] - from now, all proposed features will be publicly announced on devel-announce by the Feature Wrangler once the page content is verified for correctness and FESCo votes on Feature no sooner than a week after the announcement to encourage broader discussion. Jaroslav [1] https://fedorahosted.org/fesco/ticket/960 [2] https://fedoraproject.org/wiki/Releases/18/Schedule [3] https://fedorahosted.org/fesco/ticket/869 [3] does not look the right link -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 hostname -b foo.bar.baz
From: Frank Murphy frankl...@gmail.com In F18 su -c hostname -b foo.mylocal.stuff is not kept over a reboot. Is there a new command for doing so. Take a look at hostnamectl out of the systemd package. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: removing the non booting kernels how do I troubleshoot them?
From: Antonio Olivares wingat...@inbox.com -Original Message- From: li...@colorremedies.com Sent: Wed, 10 Oct 2012 13:02:03 -0600 To: test@lists.fedoraproject.org Subject: Re: removing the non booting kernels how do I troubleshoot them? On Oct 10, 2012, at 12:07 PM, Antonio Olivares wrote: I get dracut errors: dracut-initqueue[196]: Warning: could not boot dracut-initqueue[196]: Warning: /dev/root does not exist Entering emergency mode. Exit the shell to continue Type journalctl to view sytem logs. dracut:/#_ and it just sits there. Oh that sounds like you hit a dracut bug. If you rebuild their initramfs files with the current dracut then they will probably work. Chris Murphy -- Newer kernels = 3.6.0-2 do not boot on this toshiba laptop machine. I do not know/(have experience)/ with dracut to troubleshoot this issue. Newer 3.6.1* and today/yesterday's 3.6.2 kernels die with the same message. Can someone please suggest some commands to try out and fix this issue. https://fedoraproject.org/wiki/How_to_debug_Dracut_problems has always been good to me. I have done some netinstalls with TC3 and a newer TC4 with great success and do not see these issues! Thanks, Antonio GET FREE SMILEYS FOR YOUR IM EMAIL - Learn more at http:// www.inbox.com/smileys Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel: Request for unknown module key
From: Adam Williamson awill...@redhat.com On Mon, 2012-10-15 at 08:51 -0400, john.flor...@dart.biz wrote: From: Carl G ca...@fedoraproject.org Hello, You should consult https://fedoraproject.org/wiki/Secureboot Okay, that page certainly sounds like a good start, but it seems short on some details. My custom spin uses only Fedora-provided boot components, kernel and modules, yet I still get these messages. Just before livecd-creator reaches the %post of my kickstart, I see these: Missing EFI file (/boot/efi/EFI/*/shim.efi) Missing EFI file (/boot/efi/EFI/*/gcdx64.efi) Missing EFI file (/boot/efi/EFI/*/fonts/unicode.pf2) Failed to copy EFI files, no EFI Support will be included. Missing shim.efi, skipping efiboot.img creation. So maybe I'm just missing some new required things in my kickstart? Though Josh cleared up the issue and these messages weren't related, I thought I'd cover those too, just in case anyone else is seeing them and wondering: you'd need to have grub2-efi in your kickstart to make those go away. The only effect of not having it is that the image generated will have no UEFI support, it'll work fine in all other respects. Note that you also need livecd-creator 18.12 to get viable UEFI live images with the current F18 package set, as some files that earlier livecd-creator versions looked for were relocated or removed in other packages . Thanks Adam for that additional info. I'm going to add that to my kickstart even though I don't have EFI hardware to support, not so much to quiet the noise but more because I have the unenviable job of making a spin that will ideally work on hardware we don't own yet or may not even be manufactured yet. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel: Request for unknown module key
From: Carl G ca...@fedoraproject.org Hello, You should consult https://fedoraproject.org/wiki/Secureboot Okay, that page certainly sounds like a good start, but it seems short on some details. My custom spin uses only Fedora-provided boot components, kernel and modules, yet I still get these messages. Just before livecd-creator reaches the %post of my kickstart, I see these: Missing EFI file (/boot/efi/EFI/*/shim.efi) Missing EFI file (/boot/efi/EFI/*/gcdx64.efi) Missing EFI file (/boot/efi/EFI/*/fonts/unicode.pf2) Failed to copy EFI files, no EFI Support will be included. Missing shim.efi, skipping efiboot.img creation. So maybe I'm just missing some new required things in my kickstart? To be perfectly clear, my target hardware does not have EFI, nor do I require these secure-boot features. So do I have to just live with all this noise in the system log? Or is there a way to quiet things down a bit by installing some shim package or some such? 2012/10/11 john.flor...@dart.biz I've made a custom Live spin of F18 and why I boot the resultant image and review journalctl (for other reasons), I'm seeing quite a few instances of: kernel: Request for unknown module key 'Fedora kernel signing key: c6fb6e1f2b79b50ab078f4d6b9fc9b2204a692a7' err -11 # rpm -q kernel kernel-3.6.1-1.fc18.i686 Any idea what that's all about? -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kernel: Request for unknown module key
From: Josh Boyer jwbo...@gmail.com On Mon, Oct 15, 2012 at 9:18 AM, john.flor...@dart.biz wrote: Post the full dmesg output of the boot. There should be a section in there about loading the module signing key with a key listed. If that didn't succeed, it will produce that error message when a module is loaded, but it will still load. Okay, the entire dmesg output follows, but given what you just said, I suspect this is the important bit: [3.643056] MODSIGN: Problem loading in-kernel X.509 certificate (-129) Actually, the important bit is the few lines above that: [3.591826] Loading module verification certificates [3.601372] Cert Valid From: 2012-10-08 16:52:26 [3.610300] Cert Valid To: 2112-09-14 16:52:26 [3.618967] Now: 2003-01-01 00:02:42 [3.626830] X.509: Cert c6fb6e1f2b79b50ab078f4d6b9fc9b2204a692a7 is not yet valid [3.643056] MODSIGN: Problem loading in-kernel X.509 certificate (-129) [3.654414] registered taskstats version 1 [3.664906] Magic number: 3:0:0 [3.673116] rtc_cmos 00:04: setting system clock to 2003-01-01 00:02:44 UTC (1041379364) Your RTC thinks it's 2003. Why it does, I have no idea but that is the problem. The cert embedded in the kernel is valid from the dates listed and since your machine is telling the kernel we're back in the past it won't load. If you can get your machine to join us in this decade, the message should go away. If for some reason it really just wants to stay in 2003, the error message is just irritating. Nothing is going to be prevented from working. Oh, well that seems obvious now. I'm not sure how I missed that; likely I'm overly dependent on grep. Thank you for the detailed explanation. The RTC issue is a long standing one I've fought for some time with little success. I have a large number of PC/104 class systems that refuse to have their hardware clock become sync'd with the kernel's clock, despite variously using ntpd, chronyd, custom calls to hwclock and the stuff in the old initscripts. I've not yet looked into how systemd has replaced those parts that were in initscripts. While most of these systems never get shutdown properly -- their deployed design requirement is to simply be powered off -- I've come to believe the problem is somehow buggy hardware, although *some* units of the same make/model do sync. Sigh! :-( -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
kernel: Request for unknown module key
I've made a custom Live spin of F18 and why I boot the resultant image and review journalctl (for other reasons), I'm seeing quite a few instances of: kernel: Request for unknown module key 'Fedora kernel signing key: c6fb6e1f2b79b50ab078f4d6b9fc9b2204a692a7' err -11 # rpm -q kernel kernel-3.6.1-1.fc18.i686 Any idea what that's all about? -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Odd user/group identity lookup problem
I'm building F18 images with livecd-creator on F18 and for the first build attempt after boot, I see many unexpected errors like this snippet shows: [snip] Installing: libsemanage # [315/492] Installing: shadow-utils # [316/492] groupadd: failure while writing changes to /etc/group groupadd: failure while writing changes to /etc/group Installing: libutempter ### [317/492]warning: group utempter does not exist - using root warning: group utmp does not exist - using root Installing: libutempter # [317/492] [snip] Installing: parted # [331/492] groupadd: failure while writing changes to /etc/group useradd: group 'dhcpd' does not exist Installing: dhcp [332/492]warning: user dhcpd does not exist - using root warning: group dhcpd does not exist - using root warning: user dhcpd does not exist - using root warning: group dhcpd does not exist - using root warning: user dhcpd does not exist - using root warning: group dhcpd does not exist - using root Installing: dhcp # [332/492] [snip] Installing: os-prober# [335/492] groupadd: failure while writing changes to /etc/group Installing: openssh ## [336/492]warning: group ssh_keys does not exist - using root [snip] Installing: samba-common # [338/492] Failed to initialize SELinux context: No such file or directory Installing: iputils # [339/492] [snip] Installing: mesa-dri-drivers # [347/492] groupadd: failure while writing changes to /etc/group useradd: group 'polkitd' does not exist Installing: polkit [348/492]warning: user polkitd does not exist - using root [snip] Installing: alsa-utils # [354/492] error: %pre(rpcbind-0.2.0-17.fc18.i686) scriptlet failed, exit status 6 error: rpcbind-0.2.0-17.fc18.i686: install failed groupadd: failure while writing changes to /etc/group useradd: group 'chrony' does not exist Installing: chrony [356/492]warning: group chrony does not exist - using root Installing: chrony [356/492]warning: user chrony does not exist - using root warning: group chrony does not exist - using root warning: user chrony does not exist - using root warning: group chrony does not exist - using root Installing: chrony # [356/492] [snip] If I let it run through to completion and rerun the exact same command again, everything works normally. I used to see this behavior for every build attempt prior to sssd coming along when I was still using nscd, if nscd was running. Back then I'd have to stop nscd for the duration of the build. I never had such a problem with sssd, but this looks eerily familiar now with F18 (where I'm still using sssd instead of nscd). Has anyone else seen something similar, or is this a known bug? I have not had a chance to dig into this yet, but I've been seeing this with F18 since before Alpha was out. PS. FWIW, this F18 box started life as F17 and was been yum distro-sync'd and kept updated. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
From: Jóhann B. Guðmundsson johan...@gmail.com To: test@lists.fedoraproject.org Date: 09/24/2012 16:25 Subject: Re: Selinux in development releases Sent by: test-boun...@lists.fedoraproject.org On 09/24/2012 08:16 PM, drago01 wrote: On Mon, Sep 24, 2012 at 10:13 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: I hereby propose that we default selinux to permissive mode up to final which should just get rid of unneeded nuance during testing. -1 This would just mean we test something different then we actually ship. If there are selinux bugs they are supposed to be cough during testing and reported like any other bugs. With permissive mode we should still be able to catch all those errors and report them without all the downside that comes with having it in enforcing mode during our development releases... Not true from what I've witnessed. There are certain rules that indeed block some action, but do not get logged. I've encountered several over the years and was only able to detect these by toggling enforcing/permissive. I do wish there was some master switch to temporarily enable logging for them. I concur that Dan is superhuman in his response times. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
From: Jason L Tibbitts III ti...@math.uh.edu JF == John Florian john.flor...@dart.biz writes: JF I do wish there was some master switch to temporarily enable logging JF for them. You mean, besides the existing disable dontaudit rules switch? Just run semoduile -DB. It's pretty much mandatory to do that first when debugging selinux problems. No, that would be the one I'd want and was completely unaware of. ;-) I was going to suggest that this should be noted at http://fedoraproject.org/wiki/SELinux/Troubleshooting, but I see it already is. This just proves what I was saying about Dan's superhuman response times. He can somehow introduce just requested features prior to the present time! =) Regardless of how dumb I feel right now, thanks so much for pointing that out. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
From: Jason L Tibbitts III ti...@math.uh.edu I'm something of an idiot when it comes to selinux; I used to know just enough to get a reasonable bug report out, but now I've even forgotten most of that. I do know, however, that turning off dontaudit rules can save your sanity, because _way_ too much stuff fails silently. Which is a horrible bug in itself but it seems to be by design. I concur. I suppose there's a good reason to not log some of these, but I've nearly lost my sanity more than once with these squelched messages. Life improved only once I realized my testing was missing 'setenforce 0' to see if that had any effect. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
From: john.flor...@dart.biz I was going to suggest that this should be noted at http:// fedoraproject.org/wiki/SELinux/Troubleshooting, but I see it already is. Perhaps I should start reading all of my mail before responding to any of it. Anyway, I'm very happy to see the addition on that page. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: sudo/kerberos problems in F18
From: john.flor...@dart.biz I have sudo configured with: # Allow all members of the sudoers group (in LDAP) to run all commands. %sudoersALL=(ALL) NOPASSWD: ALL I'm a member of the sudoers group, but it is failing to authenticate me and this shows up in syslog: Aug 16 16:04:28 f18test [sssd[krb5_child[16009]]]: Credential cache directory /run/user/10325/ccdir does not exist All but the ccdir does indeed exist. Seeing krb5 mentioned here, I should note that system-auth uses Kerberos against an AD server. Debugging this a little further, I've manually created the required ccdir directory and made myself its owner. Running groups as myself, I can confirm my membership to the sudoers group. However, sudo still claims testuser is not in the sudoers file. This incident will be reported. The relevant logs capture: == /var/log/secure == Aug 17 09:34:36 f18test sudo: pam_unix(sudo:auth): authentication failure; logname=testuser uid=10325 euid=0 tty=/dev/pts/3 ruser=testuser rhost= user=testuser == /var/log/audit/audit.log == type=USER_AUTH msg=audit(1345210476.895:3118): pid=0 uid=0 auid=10325 ses=56 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct=testuser exe=/usr/bin/sudo hostname=? addr=? terminal=/dev/pts/3 res=success' == /var/log/secure == Aug 17 09:34:36 f18test sudo: pam_sss(sudo:auth): authentication success; logname=testuser uid=10325 euid=0 tty=/dev/pts/3 ruser=testuser rhost= user=testuser == /var/log/audit/audit.log == type=USER_ACCT msg=audit(1345210476.896:3119): pid=0 uid=0 auid=10325 ses=56 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct=testuser exe=/usr/bin/sudo hostname=? addr=? terminal=/dev/pts/3 res=success' type=USER_CMD msg=audit(1345210476.897:3120): pid=0 uid=0 auid=10325 ses=56 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd=/home/00/testuser cmd=date terminal=pts/3 res=failed' == /var/log/secure == Aug 17 09:34:36 f18test sudo: testuser : user NOT in sudoers ; TTY=pts/3 ; PWD=/home/00/testuser ; USER=root ; ENV=PROPHILE=/var/lib/prophile.d/jflorian GVIMINIT=source /var/lib/prophile.d/jflorian/vim/gvimrc VIMINIT=source /var/lib/prophile.d/jflorian/vim/vimrc ; COMMAND=/bin/date I'm not sure what else I can do to dig further into why sudo is failing. -- John Florian -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
SELinux blocking automounted home
My $HOME is (normally) mounted with autofs via NFS, but with F18 I am
seeing this in my audit.log:
type=AVC msg=audit(1345138563.576:2652): avc: denied { block_suspend }
for pid=3708 comm=sssd_nss capability=36
scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:sssd_t:s0
tclass=capability2
I briefly looked for new SE bools with:
# getsebool -a | egrep 'sssd|nss'
authlogin_nsswitch_use_ldap -- off
That one didn't quite sound right, but I toggled it anyway, but still no
luck. To verify basic setup, I 'setenforce 0' and tried ssh again to see
if $HOME would be mounted this time. Still no luck, so as root, I
manually tried the mount under /tmp and that did work, but also generated:
type=AVC msg=audit(1345139104.567:2687): avc: denied { block_suspend }
for pid=4084 comm=rpc.idmapd capability=36
scontext=system_u:system_r:rpcd_t:s0 tcontext=system_u:system_r:rpcd_t:s0
tclass=capability2
Known problems or am I overlooking something?
--
John Florian
Machine Data Collections Team--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: SELinux blocking automounted home
Daniel J Walsh dwa...@redhat.com wrote on 08/16/2012 14:34:01: Fixed in selinux-policy-3.11.1-9.fc18.noarch Should I be able to grab that from bodhi? If not, where can I get these newer than new builds before they reach bodhi? -- John Florian Machine Data Collections Team -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
sudo/kerberos problems in F18
I have sudo configured with: # Allow all members of the sudoers group (in LDAP) to run all commands. %sudoersALL=(ALL) NOPASSWD: ALL I'm a member of the sudoers group, but it is failing to authenticate me and this shows up in syslog: Aug 16 16:04:28 f18test [sssd[krb5_child[16009]]]: Credential cache directory /run/user/10325/ccdir does not exist All but the ccdir does indeed exist. Seeing krb5 mentioned here, I should note that system-auth uses Kerberos against an AD server. -- John Florian Machine Data Collections Team-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Preupgrade from F17 to F18 Branched
From: Adam Williamson awill...@redhat.com This is probably a terrible time to try preupgrade. It gets no major love until Beta, usually. If your goal is a working install of F18, your best option at present is a yum update from F17, following the directions at https://fedoraproject.org/wiki/ Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fedora_18 . Oh, well that would be easier for me since it stays more in my familiar realm. (Preupgrade looks neat, but my norm is fresh installs + puppet.) Should this wisdom (both waiting until Beta and that link) be incorporated into https://fedoraproject.org/wiki/Releases/Branched#Yum_update_from_previous_official_release ? Or you can wait a week or two and get the Alpha release when it comes out. If I have to I will, but where's the fun in that? ;-) I grabbed a copy of http://mirrors.fedoraproject.org/releases.txt and didn't see any mention of Fedora 18 (Branched) as indicated on the Wiki. I edited this copy to include my own Fedora 18 (Branched) section that referenced my local mirror and then got much further. It's probably a little early post-F18 for all this to be in place, but releases.txt does need updating. Nice to know, thanks. I'm having lots of fun seeing what it takes to get Fedora out the door since I'm making my own derived Live spins for internal company use on embedded systems. I face many of the same challenges. -- John Florian Machine Data Collections Team -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Preupgrade from F17 to F18 Branched
From: Adam Williamson awill...@redhat.com This is probably a terrible time to try preupgrade. It gets no major love until Beta, usually. If your goal is a working install of F18, your best option at present is a yum update from F17, following the directions at https://fedoraproject.org/wiki/ Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fedora_18 . Oh, well that would be easier for me since it stays more in my familiar realm. (Preupgrade looks neat, but my norm is fresh installs + puppet.) Should this wisdom (both waiting until Beta and that link) be incorporated into https://fedoraproject.org/wiki/Releases/ Branched#Yum_update_from_previous_official_release? Probably not. Actually I should have written that a bit differently: it's a *good* thing from a QA perspective that you're trying preupgrade now and finding the bugs. We want them found early. It's only a bad thing from the point of view that it has about 0% chance of succeeding. =) Even if you get the preupgrade bit working, I believe newUI anaconda does not actually implement upgrades yet, so there is no chance the anaconda bit of the process will work. Cool. Let us know if you find any QA process documentation missing - I think we cover it pretty well though :) It is covered pretty well. For some reason though, when I first sought out pages telling me how to get on rawhide (because 18 hadn't been branched just yet), I never stumbled onto the Upgrading_Fedora_using_yum page. I mostly got a rawhide box based on intuition, but that page clearly documents some things I hadn't thought about. My suggestion for incorporating this link into the Releases/Branched page was primarily based on the impression that the former covered that specific topic more thoroughly. Thus I kind of envisioned something akin to: Yum update from previous official release This method is available but generally not recommended. Anaconda can make changes that are outside what the packaging system can normally deal with. You may also run into dependency problems which could take time to untangle. You may also need to upgrade from the immediately previous release (e.g. install Fedora 12, then Fedora 14 Branched, not jump directly from Fedora 12 to Fedora 14 Branched). Be prepared to wipe your system and re-install from scratch if things do not go well. If you decide to go this route anyway, please see http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum Also, that paragraph is just plain confusing (to me, at least). After trying to parse it for a while, I think it's trying to say: You may *first* need to upgrade *to* the immediately previous release (e.g. install/upgrade to Fedora *13*, then Fedora 14 Branched, not jump directly from Fedora 12 to Fedora 14 Branched). -- John Florian Machine Data Collections Team -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
