Re: What are reasonable blockers for making journald the default logger in F19?
On 10/17/2012 07:44 AM, Matthew Miller wrote: > With the stipulation that rsyslog would still be available to provide a > traditional syslog-style text logs, what are reasonable hard requirements > for making systemd the main logging system installed by default? (Or, an > alternate softer implementation: rsyslogd would be installed by default but > would not be in 'core'.) > > These are the things I think are critical: > ... > > Less critical but important: Another thing I've been looking for but not seen any mention of is a mechanism for keeping some types of journaled messages longer than others. E.g. for a mail server with a web front end, you might want to keep the maillogs around much longer than the httpd access_log & error_log (though I'm not clear yet whether those will be replaced by journald, given how httpd handles logging, but it's an example). Or, similarly, different maximum data sizes for different services. As poorly as I understand it yet, I don't think it looks like journald has a way to do this yet; everything seems to share the same limits, if any. A way to specify for the different messages would be a nice thing. -- J. Randall Owens | http://www.ghiapet.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 2012-10-17 at 18:20 -0400, Andrew Schultz wrote: > Simo Sorce wrote: > > All very nice, but the current situation is that this info *is* sent to > > the log. > > So I applaud if you want to go and fix applications, in the meanwhile we > > cannot relax security around that log IMO. > > The current situation (from where I'm sitting) is that the private info > is *not* sent to the log because the of the gdm chooser design. So what > we have instead is that non-private info is being sent to a > super-private log and (as Lennart pointed out) that information is less > accessible to the admins that might be able to use it. gdm is only one of the entry points. The console still asks for a user name, it does not present a chooser. And the console is the default prompt for a lot of use cases (VMs in labs, etc...). > If you are concerned about people not using the chooser or some other > vector to hit the issue with pam, then fixing pam is a ~1 line patch (if > people can be convinced that the info shouldn't be logged). I can't > imagine too many other applications having this bad behavior (given that > I never see passwords in the logs anymore). I don't know what we > accomplish by protecting AUTHPRIV as a facilitator of applications > logging things that shouldn't be logged. You protect the innocent users.Before you can say it is a oneliner you should perform an audit and check what logs with authpriv on fedora and then see what is logged. It is not an easy task, there isn't just PAM modules although those are prime targets. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
aha! I figured out why journalctl's auto-pager bugs me when git's doesn't (and possible solution)
Again, this is with the prefix that this isn't a big deal; it's a matter of polish. But, here's the difference between `man` and `git log` automatically sending output to a pager: Man is a document reader. When you run it, you start at the top and read down. A pager is natural. The git log command is _reverse sorted_. So, again, the most useful and relevant information is at the top. Cool. With log information, unless explicitly searching, it's almost always the _end_ that's most interesting. So, every time I run it, I'm looking at "boring" old information, and have to scroll to the bottom (with `G` or `End`). Not so cool. If it just spit out the entire information, it'd all scroll past, and I could use my terminal's buffer to scroll back, or decide to pipe to a command (a typical log-checking workflow would be to use grep, but journalctl's filters are helpful here). So, possible solutions: - reverse-sort the log entries, a la `git log` (I don't think anyone really wants this) - don't auto-page; enable that with a flag (I know Lennart does not like this; okay, fair enough) - change the default less options to include +G, which jumps to the end of the file. (I'd also suggest adding the -M option to show line numbers -- it's nice, and makes it more clear that scrolling up is an option) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 3:43 PM, Reindl Harald wrote: > Am 17.10.2012 18:52, schrieb Dave Jones: >> With virtualised environments supporting pci/usb passthrough, where do you >> draw the line on what hardware to support in a hypothetical kernel-cloud >> package ? > > with vmxnet3, vmw_pvscsi, vmw_balloon to support vSphere > (all included in the upstream kernel) and the drivers > for basic KVM guests + all the iptabales (nat, conntrack, > rectent, multiport..) you are sipporting a really wide range > of minimized-size and full functional setups And xen and whatever it needs. I mean, if you're targeting virt and cloud, then you can't ignore EC2 and that is all xen. And hyper-v. Can't exclude them either. And whatever Rusty's virt thing is. And on and on. About the only "virt/cloud" thing you can exclude is e.g. virtualbox and that's only because they're not in the upstream kernel. Maybe one day they'll realize the error of their ways and then you have to include that too. > 99 out of 100 doe snot passthru physical hardware Maybe today, but it's an ever increasing target. I don't think it can be entirely dismissed. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 2:38 PM, Jesse Keating wrote: > On 10/17/2012 11:32 AM, Chris Adams wrote: >> >> I would think the only "sane" way would be to just change the packaing, >> not actually build multiple kernels (or even multiple packages with >> kernels). We already build multiple kernels. All from the same source, but still multiple kernels with different config options. E.g. PAE, debug, etc. >> For example, a "kernel-minimal" that has the kernel and the "core" >> modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, >> network support like ipv6 and iptables, and virtio-type drivers), a >> "kernel-common" that has the rest of the current contents of "kernel" >> (and probably obsoletes "kernel"), and then the current >> "kernel-modules-extras". >> >> There will always be requests to move modules from -common to -minimal, >> and it shouldn't be a big fight (I would bet most requests would be >> pretty obvious). That already exists some for -modules-extras. > > > You'd want to do it something like that. > > kernel-minimal as you say but with a Provides: kernel, kernel-common as you > say. > > > I'd introduce a third metapackage just "kernel" that requires both of those > and implicitly Provides: kernel. Most people would just get the "kernel" > metapackage when a transaction asks for something to provide "kernel", but > if you explicitly ask for kernel-minimal you'd get just the minimal. > > This would all be done from one kernel spec and built out at the same time. > We've got a lot of new infrastructure coming for kernel builds and we don't > want to make things even more complicated by having to do multiple rpm build > runs. All of this can probably already be done with a new 'flavor' in the existing kernel.spec. I really wouldn't do the common/minimal split though. It just makes it more complicated for not a whole lot of gain. The idea that Dave, Justin, and Kevin all had simlutaneously about doing a 'kernel-virtguest' might be worthwhile if someone wants to spend time poking at a config, etc. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Simo Sorce wrote: All very nice, but the current situation is that this info *is* sent to the log. So I applaud if you want to go and fix applications, in the meanwhile we cannot relax security around that log IMO. The current situation (from where I'm sitting) is that the private info is *not* sent to the log because the of the gdm chooser design. So what we have instead is that non-private info is being sent to a super-private log and (as Lennart pointed out) that information is less accessible to the admins that might be able to use it. If you are concerned about people not using the chooser or some other vector to hit the issue with pam, then fixing pam is a ~1 line patch (if people can be convinced that the info shouldn't be logged). I can't imagine too many other applications having this bad behavior (given that I never see passwords in the logs anymore). I don't know what we accomplish by protecting AUTHPRIV as a facilitator of applications logging things that shouldn't be logged. -- Andrew Schultz aj...@buffalo.edu http://www.sens.buffalo.edu/~ajs42/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting minutes 2012-10-17
Good day all, Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-10-17/fedora-meeting-1.2012-10-17-20.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-10-17/fedora-meeting-1.2012-10-17-20.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-10-17/fedora-meeting-1.2012-10-17-20.00.log.html Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On 10/17/2012 01:46 PM, David Malcolm wrote: Random worry about this: would this work OK with yum's "keep the last 3 kernels around" functionality? That's obviously something that would have to be tested if this is attempted. I'm not signing up for this work, I was just making a suggestion on how to structure the rpms that fell out of the kernel spec. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 2012-10-17 at 14:52 -0400, Simo Sorce wrote: > > To my knowledge AUTHPRIV is simply for authorization-related data, not > > for the seccret auth tokens themselves. The Linux man page suggests that > > AUTH is obsolete, and AUTHPRIV is what people should use for all auth > > related stuff. And if things get specific this is mostly about "user > > logged in", "user changed password", but never "user changed password > > to xyz". > > Sigh, I guess I need to be more explicit, you can find messages like: > > User MySecretPassword failed authentication. > > Because mistakenly a user typed his password at the login prompt instead > of his name. It is common. As an anecdata point, I've done this on websites twice in the last two days. So I'm inclined to believe Simo :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, Oct 17, 2012 at 10:02 PM, Matthew Miller wrote: > On Wed, Oct 17, 2012 at 09:39:43PM +0200, drago01 wrote: >> > I don't know if it's more likely. It's seems to be almost a tautology that >> > corrupt binary formats are more problematic. Just the other day I hit >> > something that caused a corrupted journal and made journalctl stop telling >> > me things. (bz 865091) I really was at a loss as to what to do. That might >> > have just been a weird glitch, but... well, isn't that the point? >> Well binary does not imply encrypted ... you can still extract data >> out of "unreadable" journal files. > > Yes, but I think we can all agree that the level difficulty and knowledge > required is usually higher. Sure was just pointing out that it isn't the "all or nothing" thing people seem to talk about. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, 2012-10-17 at 11:38 -0700, Jesse Keating wrote: > On 10/17/2012 11:32 AM, Chris Adams wrote: > > I would think the only "sane" way would be to just change the packaing, > > not actually build multiple kernels (or even multiple packages with > > kernels). > > > > For example, a "kernel-minimal" that has the kernel and the "core" > > modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, > > network support like ipv6 and iptables, and virtio-type drivers), a > > "kernel-common" that has the rest of the current contents of "kernel" > > (and probably obsoletes "kernel"), and then the current > > "kernel-modules-extras". > > > > There will always be requests to move modules from -common to -minimal, > > and it shouldn't be a big fight (I would bet most requests would be > > pretty obvious). That already exists some for -modules-extras. > > You'd want to do it something like that. > > kernel-minimal as you say but with a Provides: kernel, kernel-common as > you say. > > > I'd introduce a third metapackage just "kernel" that requires both of > those and implicitly Provides: kernel. Most people would just get the > "kernel" metapackage when a transaction asks for something to provide > "kernel", but if you explicitly ask for kernel-minimal you'd get just > the minimal. > > This would all be done from one kernel spec and built out at the same > time. We've got a lot of new infrastructure coming for kernel builds > and we don't want to make things even more complicated by having to do > multiple rpm build runs. Random worry about this: would this work OK with yum's "keep the last 3 kernels around" functionality? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Lennart Poettering (mzerq...@0pointer.de) said: > To end this bit of the discussion too, I have now added a README that is > installed to /var/log/README and one that ends up in > /etc/rc.d/init.d/README, and should help the user to find the new tool > set. Should hit F18 soon. Given we default to rsyslog in F18, please don't put a /var/log/README there - that would just confuse things. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On Wed, 2012-10-17 at 14:31 -0600, Jeff Law wrote: > On 10/17/2012 02:26 PM, Simo Sorce wrote: > > On Wed, 2012-10-17 at 14:12 -0600, Jeff Law wrote: > >> On 10/17/2012 11:07 AM, Simo Sorce wrote: > >>> > >>> Personally I do not like the nss_init() calls, it will just make it even > >>> more difficult to diagnose 'heisenbugs' when some apps start doing it, > >>> some don't and some other do it at the wrong time. > >>> > >>> I would rather have glibc do it automatically with rate limiting. > >>> Like no more than once every 3 minutes do a stat on one of the getent > >>> calls and reload if necessary, still this would be thousands of > >>> unnecessary (vs 0 necessary) stat() calls every day, not the best > >>> solution. > >> Rather than polling, why not use inotify? > > > > Because you do not want to have one inotify file descriptor open for > > each and every process in your system, it consumes system resources for > > no good reason. > Certainly wouldn't have one for each and every process, they'd be lazily > set up. However, even with lazy setup, we're probably still burning too > many fds. Given that a truckload of libraries touch the nsswitch interface it would still be most processes IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On Wed, 2012-10-17 at 14:12 -0600, Jeff Law wrote: > On 10/17/2012 11:07 AM, Simo Sorce wrote: > > > > Personally I do not like the nss_init() calls, it will just make it even > > more difficult to diagnose 'heisenbugs' when some apps start doing it, > > some don't and some other do it at the wrong time. > > > > I would rather have glibc do it automatically with rate limiting. > > Like no more than once every 3 minutes do a stat on one of the getent > > calls and reload if necessary, still this would be thousands of > > unnecessary (vs 0 necessary) stat() calls every day, not the best > > solution. > Rather than polling, why not use inotify? Because you do not want to have one inotify file descriptor open for each and every process in your system, it consumes system resources for no good reason. > However, this really needs to be taken upstream (libc-alpha). I'm not > in a position to champion this kind of change. True, but I haven;t done anything so far because I can't see a good solution. It's the same problem we have with resolv.conf, there too I think the solution is not res_init() but to have a default dns caching daemon, and have resolv.conf permanently welded to 127.0.0.1, but that's just me. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Am 17.10.2012 18:52, schrieb Dave Jones: > With virtualised environments supporting pci/usb passthrough, where do you > draw the line on what hardware to support in a hypothetical kernel-cloud > package ? with vmxnet3, vmw_pvscsi, vmw_balloon to support vSphere (all included in the upstream kernel) and the drivers for basic KVM guests + all the iptabales (nat, conntrack, rectent, multiport..) you are sipporting a really wide range of minimized-size and full functional setups 99 out of 100 doe snot passthru physical hardware signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Am 17.10.2012 18:13, schrieb Jóhann B. Guðmundsson: > On 10/17/2012 03:50 PM, Lennart Poettering wrote: >> the files are stored in >> /var/log/journal/ > > Is it not better to place this under /var/journal/ and leave text files > to /var/log/ to prevent administrators thinking they can treat the journal > files a text files and prevent any kind of script breakage that expect all > files in that directory to be text files? please keep in mind that there are many setups with /var/log on a dedicated partition / virtual-drive and maybe more people as i upgrade since our currecnt setups are origin F9-installs upgraded up to F17 with yum i even go so far to seperate /var/log and /var/cache on own v-disks to have a easy as possible method resize them if needed in the future signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 2012-10-17 at 16:01 -0400, Andrew Schultz wrote: > Matthew Miller wrote: > > On Wed, Oct 17, 2012 at 03:07:19PM -0400, Andrew Schultz wrote: > >> and if you log all attempts to login, then they'll end up in the > >> logs. I'd suggest that not logging unknown users by default is a > >> much better solution than having a special log; no admin wants to > >> see passwords (even if they're root) and unknown usernames (either > >> typos or passwords) are rarely helpful. > > > > I don't think that's true. "You're typing the wrong username" happened to me > > on multiple occasions when I was doing that kind of support. > > I don't have a problem with logging the fact that a user attempted to > log in with an unknown username, and that would be sufficient for the > your diagnosis (if you can correlate times). If you can't correlate > times, then you get to scrape the logs looking for similar but invalid > usernames. A simple "what user name are you trying to log in as?" would > go much faster. > > > Additionally, it maybe useful to log this information for intrusion > > detection and correlation. > > Again, you don't need to know that the attacker guessed a username of > "bob". You simply need to recognize that N attempts were made to log in > with unknown usernames during some time period. > > > And, in general, authpriv exists as a mechanism for logging any sort of > > potentially private data. It would be a security regression to ignore that. > > Not seeing useless (typos) and confidential (passwords) information is > not a security regression. And I'm having trouble thinking of other > information that is super-private (should only be seen by root) and useful. All very nice, but the current situation is that this info *is* sent to the log. So I applaud if you want to go and fix applications, in the meanwhile we cannot relax security around that log IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, 17 Oct 2012 14:40:39 -0400 Matthew Miller wrote: > On Wed, Oct 17, 2012 at 11:38:13AM -0700, Jesse Keating wrote: > > I'd introduce a third metapackage just "kernel" that requires both > > of those and implicitly Provides: kernel. Most people would just > > get the "kernel" metapackage when a transaction asks for something > > to provide "kernel", but if you explicitly ask for kernel-minimal > > you'd get just the minimal. > > +1 to this I think we should really avoid calling this "minimal" as we have seen that means different things to different folks. if someone wanted to explore this route, I would say call it 'kernel-virt-guest' or something similar. Establish exactly what virt env's are targeted by it, do some test runs to show that it helps anyone at all, and then sell it to the kernel maintainers. ;) Sounds like it could be a nice f19 feature if there are folks interested enough to work on it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Samsung RF-511 wpa_supplicant crashes under kernel 3.6.1-1.fc17.x86_64
Problem solved with new akmod-wl. Thanks, Best regards, CdAB signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, Oct 17, 2012 at 09:39:43PM +0200, drago01 wrote: > > I don't know if it's more likely. It's seems to be almost a tautology that > > corrupt binary formats are more problematic. Just the other day I hit > > something that caused a corrupted journal and made journalctl stop telling > > me things. (bz 865091) I really was at a loss as to what to do. That might > > have just been a weird glitch, but... well, isn't that the point? > Well binary does not imply encrypted ... you can still extract data > out of "unreadable" journal files. Yes, but I think we can all agree that the level difficulty and knowledge required is usually higher. I don't want to hash over the virtues or downsides of a binary journal. That's what it is. My concern is that Fedora users are equipped with the tools and information to have a ... well, if not a _good_ experience, at least a _not terrible_ experience ... when things do go wrong. And to make sure that we've done our homework in avoiding as many problems as possible. (Referring back to the start of this sub-thread, I'm asking for documentation and for a testing and qa plan to be a requirement for the feature schedule. Nothing more.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Matthew Miller wrote: On Wed, Oct 17, 2012 at 03:07:19PM -0400, Andrew Schultz wrote: and if you log all attempts to login, then they'll end up in the logs. I'd suggest that not logging unknown users by default is a much better solution than having a special log; no admin wants to see passwords (even if they're root) and unknown usernames (either typos or passwords) are rarely helpful. I don't think that's true. "You're typing the wrong username" happened to me on multiple occasions when I was doing that kind of support. I don't have a problem with logging the fact that a user attempted to log in with an unknown username, and that would be sufficient for the your diagnosis (if you can correlate times). If you can't correlate times, then you get to scrape the logs looking for similar but invalid usernames. A simple "what user name are you trying to log in as?" would go much faster. Additionally, it maybe useful to log this information for intrusion detection and correlation. Again, you don't need to know that the attacker guessed a username of "bob". You simply need to recognize that N attempts were made to log in with unknown usernames during some time period. And, in general, authpriv exists as a mechanism for logging any sort of potentially private data. It would be a security regression to ignore that. Not seeing useless (typos) and confidential (passwords) information is not a security regression. And I'm having trouble thinking of other information that is super-private (should only be seen by root) and useful. -- Andrew Schultz aj...@buffalo.edu http://www.sens.buffalo.edu/~ajs42/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, Oct 17, 2012 at 9:32 PM, Matthew Miller wrote: > On Wed, Oct 17, 2012 at 11:04:28AM -0400, Simo Sorce wrote: >> > 6. Strong QA exploring corner cases and data corruption (procedure tbd) >> > 7. Clear, simple, and Fedora-centric disaster recovery documentation >> I am not sure 6/7 are strong requisites. We certainly shipped stuff that >> was hard to deal with when it broke before. >> I would love to see this done for F19 but I think it would be unfair to >> block the feature just on point 6/7 unless there is a significant higher >> risk of issues with the journal than there ever was with malfunctioning >> (r)syslog. >> >> Is your worry that because the journal file is a binary format and not a >> plain text file that corruption of the journal files is more likely / >> more problematic ? > > It isn't that systemd/journald are particularly unreliable or risky > inherently. It's just a big change, which is a big risk *for Fedora*, and we > should be extra diligent so that the reception is positive. It doesn't take > many undiscovered corner cases to make the change a fiasco. > > The quality assurance process here doesn't need to be turned up to 11, but > it does need to at least be thorough. Likewise the DR documentation will > help ease the transition simply by existing. (And here, I'm not just talking > about recovering from systemd failures, but, for example hardware failure > that corrupts the journal, or simply takes down the machine so dead-system > forensics are required.) > >> Is your worry that because the journal file is a binary format and not a >> plain text file that corruption of the journal files is more likely / >> more problematic ? > > I don't know if it's more likely. It's seems to be almost a tautology that > corrupt binary formats are more problematic. Just the other day I hit > something that caused a corrupted journal and made journalctl stop telling > me things. (bz 865091) I really was at a loss as to what to do. That might > have just been a weird glitch, but... well, isn't that the point? Well binary does not imply encrypted ... you can still extract data out of "unreadable" journal files. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 17.10.12 17:50, Lennart Poettering (mzerq...@0pointer.de) wrote: > On Wed, 17.10.12 17:07, Benny Amorsen (benny+use...@amorsen.dk) wrote: > > > Matthew Miller writes: > > > > > Less critical but important: > > > > A hard link to an easier-to-guess name like logread (used by OpenWRT)? > > Instead of introducing new aliases and ambiguities by introducing yet > another name that has no relation to the subsystem otherwise (afterall, > the server-side is called journald, the files are stored in > /var/log/journal/ and have the suffix .journal, and so on) we should > really focus on making it easy to discover the new tool, under its right > name. One way to achieve that should be to provide /var/log/README with > the appropriate hints, since I assume much more people will look for > logs in /var/log like it used to be in most of Linux history rather than > in a tool "logread" that is known by an embedded distro by the name of > OpenWRT... To end this bit of the discussion too, I have now added a README that is installed to /var/log/README and one that ends up in /etc/rc.d/init.d/README, and should help the user to find the new tool set. Should hit F18 soon. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, Oct 17, 2012 at 11:04:28AM -0400, Simo Sorce wrote: > > 6. Strong QA exploring corner cases and data corruption (procedure tbd) > > 7. Clear, simple, and Fedora-centric disaster recovery documentation > I am not sure 6/7 are strong requisites. We certainly shipped stuff that > was hard to deal with when it broke before. > I would love to see this done for F19 but I think it would be unfair to > block the feature just on point 6/7 unless there is a significant higher > risk of issues with the journal than there ever was with malfunctioning > (r)syslog. > > Is your worry that because the journal file is a binary format and not a > plain text file that corruption of the journal files is more likely / > more problematic ? It isn't that systemd/journald are particularly unreliable or risky inherently. It's just a big change, which is a big risk *for Fedora*, and we should be extra diligent so that the reception is positive. It doesn't take many undiscovered corner cases to make the change a fiasco. The quality assurance process here doesn't need to be turned up to 11, but it does need to at least be thorough. Likewise the DR documentation will help ease the transition simply by existing. (And here, I'm not just talking about recovering from systemd failures, but, for example hardware failure that corrupts the journal, or simply takes down the machine so dead-system forensics are required.) > Is your worry that because the journal file is a binary format and not a > plain text file that corruption of the journal files is more likely / > more problematic ? I don't know if it's more likely. It's seems to be almost a tautology that corrupt binary formats are more problematic. Just the other day I hit something that caused a corrupted journal and made journalctl stop telling me things. (bz 865091) I really was at a loss as to what to do. That might have just been a weird glitch, but... well, isn't that the point? > I was wondering if /var/log/messages could be turned into a named pipe > to which journal start spitting out stuff in syslog format when someone > tails it ? I think the semantics of named pipes are enough different that this might actually make the transition worse, as nice as it would be for something like that to magically work. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, Oct 17, 2012 at 03:07:19PM -0400, Andrew Schultz wrote: > and if you log all attempts to login, then they'll end up in the > logs. I'd suggest that not logging unknown users by default is a > much better solution than having a special log; no admin wants to > see passwords (even if they're root) and unknown usernames (either > typos or passwords) are rarely helpful. I don't think that's true. "You're typing the wrong username" happened to me on multiple occasions when I was doing that kind of support. Additionally, it maybe useful to log this information for intrusion detection and correlation. And, in general, authpriv exists as a mechanism for logging any sort of potentially private data. It would be a security regression to ignore that. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Lennart Poettering wrote: So, that passwords are logged to authpriv appears to be fabrication to me. Can you point me to something reliable that people understood it that way, that code is actually doing this, or even best, that authpriv was actually supposed to be used for logs like that? In the not-to-distant past when users had to type in their login names (instead of choosing from a list), users would sometimes type their passwords instead (perhaps thinking the screensaver was locked). PAM apparently concluded the sky was falling and sent something to the logs as LOG_CRIT, and the logs would then contain "unknown user XYZ tried to log in" (where XYZ was the users password). As a bonus, logwatch would then happily send these to me in an email [I patched pam locally to consider it LOG_NOTICE]. The switch to the current chooser has eliminated this problem for me, but there might be other contexts where a user might inadvertently type in their password where the username is desired and if you log all attempts to login, then they'll end up in the logs. I'd suggest that not logging unknown users by default is a much better solution than having a special log; no admin wants to see passwords (even if they're root) and unknown usernames (either typos or passwords) are rarely helpful. -- Andrew Schultz aj...@buffalo.edu http://www.sens.buffalo.edu/~ajs42/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 2012-10-17 at 20:39 +0200, Lennart Poettering wrote: > On Wed, 17.10.12 12:58, Simo Sorce (s...@redhat.com) wrote: > > > On Wed, 2012-10-17 at 17:45 +0200, Lennart Poettering wrote: > > > On Wed, 17.10.12 10:44, Matthew Miller (mat...@fedoraproject.org) wrote: > > > > > > > 2. Mechanism for separation of authpriv data > > > > > > Humm, so, I have my doubts that this really is desirable... > > > > > > "because syslog did it this way too" doesn't sound like a really good > > > reason for this. > > > > No you are getting it wrong here. > > > > It's not that syslog did it this way. > > > > But syslog was configured explicitly this way and on purpose, if it were > > logsys instead of syslog we'd still have the same configuration done by > > the maintainers of the distro. > > > > The point is that the authpriv target gets data from pam/login > > applications and it is *normal* to have leaked password sin there. > > So it should not be readable by anyone but root. > > Or a leaked password suddenly becomes a privilege escalation issue > > instead of just an annoyance. > > So, that passwords are logged to authpriv appears to be fabrication to > me. Can you point me to something reliable that people understood it > that way, that code is actually doing this, or even best, that authpriv > was actually supposed to be used for logs like that? > > To my knowledge AUTHPRIV is simply for authorization-related data, not > for the seccret auth tokens themselves. The Linux man page suggests that > AUTH is obsolete, and AUTHPRIV is what people should use for all auth > related stuff. And if things get specific this is mostly about "user > logged in", "user changed password", but never "user changed password > to xyz". Sigh, I guess I need to be more explicit, you can find messages like: User MySecretPassword failed authentication. Because mistakenly a user typed his password at the login prompt instead of his name. It is common. > Can you back up your claim that AUTHPRIV is supposed to be good for > logging passwords, or that existing code uses it that way? No because that is not the claim, I said LEAKED, not shown on purpose. > If that's not the case then it should be sufficient to protect the > journal files that non-privileged users can't read them, and only users > in the special group "adm" can. That is already quite a stringent > protection. I mean, I am not suggesting making anything > world-readable. These files are only readable by "adm" users, i.e. users > deemed trustable enough to read system logs. adm is not root, if root leaks his password there then you have a problem if users in adm can read it. > > It is superduper necessary by default, because you can't close the barn > > *after* the sheep have escaped. > > Well, the sheep won't escape anyway since normal users are not in > "adm". You better know what you do if you add a user to "adm". If you trust the user ultimately you give him root, if you put it in adm instead it is because you do not trust him with the root password. Se the example above and connect the dots. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, Oct 17, 2012 at 08:41:49PM +0200, Lennart Poettering wrote: > There are already various non-text file formats used in /var/log, fore > example btmp and wtmp, bootchart, lastlog, and I think even mysql > sometimes puts its binary logs there... > I think it's a good idea to have a single point where log-style data is > stored, regardless of the format used... I agree. So does the FHS. But, that said, these things seem like _implementation details_ and not feature blockers. Can we either step back and look at the larger picture, or else hear an argument for why this would be really, really important? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 17.10.12 16:13, "Jóhann B. Guðmundsson" (johan...@gmail.com) wrote: > On 10/17/2012 03:50 PM, Lennart Poettering wrote: > >the files are stored in > >/var/log/journal/ > > Is it not better to place this under /var/journal/ and leave text > files to /var/log/ to prevent administrators thinking they can treat > the journal files a text files and prevent any kind of script > breakage that expect all files in that directory to be text files? There are already various non-text file formats used in /var/log, fore example btmp and wtmp, bootchart, lastlog, and I think even mysql sometimes puts its binary logs there... I think it's a good idea to have a single point where log-style data is stored, regardless of the format used... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 11:38:13AM -0700, Jesse Keating wrote: > I'd introduce a third metapackage just "kernel" that requires both > of those and implicitly Provides: kernel. Most people would just > get the "kernel" metapackage when a transaction asks for something > to provide "kernel", but if you explicitly ask for kernel-minimal > you'd get just the minimal. +1 to this -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 01:32:23PM -0500, Chris Adams wrote: > There will always be requests to move modules from -common to -minimal, > and it shouldn't be a big fight (I would bet most requests would be > pretty obvious). That already exists some for -modules-extras. That's why I suggest defining the specific targets (for example, EC2, KVM) for the core package. The requirements may grow and change slightly, but in general it provides a simple test, with no fighting needed. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 17.10.12 12:58, Simo Sorce (s...@redhat.com) wrote: > On Wed, 2012-10-17 at 17:45 +0200, Lennart Poettering wrote: > > On Wed, 17.10.12 10:44, Matthew Miller (mat...@fedoraproject.org) wrote: > > > > > 2. Mechanism for separation of authpriv data > > > > Humm, so, I have my doubts that this really is desirable... > > > > "because syslog did it this way too" doesn't sound like a really good > > reason for this. > > No you are getting it wrong here. > > It's not that syslog did it this way. > > But syslog was configured explicitly this way and on purpose, if it were > logsys instead of syslog we'd still have the same configuration done by > the maintainers of the distro. > > The point is that the authpriv target gets data from pam/login > applications and it is *normal* to have leaked password sin there. > So it should not be readable by anyone but root. > Or a leaked password suddenly becomes a privilege escalation issue > instead of just an annoyance. So, that passwords are logged to authpriv appears to be fabrication to me. Can you point me to something reliable that people understood it that way, that code is actually doing this, or even best, that authpriv was actually supposed to be used for logs like that? To my knowledge AUTHPRIV is simply for authorization-related data, not for the seccret auth tokens themselves. The Linux man page suggests that AUTH is obsolete, and AUTHPRIV is what people should use for all auth related stuff. And if things get specific this is mostly about "user logged in", "user changed password", but never "user changed password to xyz". Can you back up your claim that AUTHPRIV is supposed to be good for logging passwords, or that existing code uses it that way? If that's not the case then it should be sufficient to protect the journal files that non-privileged users can't read them, and only users in the special group "adm" can. That is already quite a stringent protection. I mean, I am not suggesting making anything world-readable. These files are only readable by "adm" users, i.e. users deemed trustable enough to read system logs. > It is superduper necessary by default, because you can't close the barn > *after* the sheep have escaped. Well, the sheep won't escape anyway since normal users are not in "adm". You better know what you do if you add a user to "adm". Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On 10/17/2012 11:32 AM, Chris Adams wrote: I would think the only "sane" way would be to just change the packaing, not actually build multiple kernels (or even multiple packages with kernels). For example, a "kernel-minimal" that has the kernel and the "core" modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, network support like ipv6 and iptables, and virtio-type drivers), a "kernel-common" that has the rest of the current contents of "kernel" (and probably obsoletes "kernel"), and then the current "kernel-modules-extras". There will always be requests to move modules from -common to -minimal, and it shouldn't be a big fight (I would bet most requests would be pretty obvious). That already exists some for -modules-extras. You'd want to do it something like that. kernel-minimal as you say but with a Provides: kernel, kernel-common as you say. I'd introduce a third metapackage just "kernel" that requires both of those and implicitly Provides: kernel. Most people would just get the "kernel" metapackage when a transaction asks for something to provide "kernel", but if you explicitly ask for kernel-minimal you'd get just the minimal. This would all be done from one kernel spec and built out at the same time. We've got a lot of new infrastructure coming for kernel builds and we don't want to make things even more complicated by having to do multiple rpm build runs. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Once upon a time, Richard W.M. Jones said: > It really depends on what 'kernel-minimal' is. If it's the > same kernel (identical vmlinuz) with groups of modules, then I'm > assuming this is the same as what everyone else is proposing. I would think the only "sane" way would be to just change the packaing, not actually build multiple kernels (or even multiple packages with kernels). For example, a "kernel-minimal" that has the kernel and the "core" modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, network support like ipv6 and iptables, and virtio-type drivers), a "kernel-common" that has the rest of the current contents of "kernel" (and probably obsoletes "kernel"), and then the current "kernel-modules-extras". There will always be requests to move modules from -common to -minimal, and it shouldn't be a big fight (I would bet most requests would be pretty obvious). That already exists some for -modules-extras. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 07:34:22PM +0200, drago01 wrote: > If it is all about using kernel-minimal (or whatever it is called) > instead of kernel there is no extra work for the ones that build > minimal images at all. It really depends on what 'kernel-minimal' is. If it's the same kernel (identical vmlinuz) with groups of modules, then I'm assuming this is the same as what everyone else is proposing. But more dangerous if this is a recompile of the kernel (maybe same source, different configs). Then inevitably we're testing different codepaths. [...] > > Unfortunately containers don't work for every application out there. > > Obviously *if* you can use a container, then you should, and you > > probably are already. > > That might be true but I can't think of such applications right now. > Couldn't the applications you have in mind be modified / fixed to work > in such an environment? LXC isn't a secure alternative to full virtualization -- try poking random /sys files on your container -- and even now OpenVZ isn't quite upstream. Also clouds are existing ecosystems. For example I can't call up Amazon and ask that they reimplement their service on top of LXC instead of Xen. > In that case you should place the image on your internal network. Well, no. I don't colocate with everyone who might want to download a minimal image. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On Thu, Aug 09, 2012 at 09:05:26PM +0300, Pasi Kärkkäinen wrote: > On Tue, Jul 31, 2012 at 08:33:04PM +0100, Matthew Garrett wrote: > > On Tue, Jul 31, 2012 at 10:27:54PM +0300, Pasi Kärkkäinen wrote: > > > > > .. and it's stuck there. I need to press Reset button to continue. > > > It did read the CD for a while until it got frozen. > > > > Yeah, that's definitely a bug then. We'll see if we can reproduce it. > > > > Any luck reproducing? Anything else I should try? > Ok, this issue is now resolved. It was an Intel BIOS/firmware bug. DQ77MK BIOS v0050 has this in the changelog/releasenotes: "Fixed issue with UEFI Linux* installation." And indeed, with BIOS 0050 I can now successfully UEFI boot both Fedora 17 and RHEL 6.3. Thanks a lot to everyone involved! -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Please review your packages against the list of services started by default
Hello all, On Wed, Oct 17, 2012 at 7:40 PM, Miloslav Trmač wrote: > * #950 Cleanup of the default enabled services list (mitr, 17:11:50) > * AGREED: Will revisit when there is a list of specific changes > (mitr, 17:17:30) Please review https://fedoraproject.org/wiki/Starting_services_by_default and how it applies to your packages: * If your package starts by default, is it allowed by the policy? If not, should it be added as an exception? * If your package currently has an exception, is it still starting by default? If not, should the exception be removed? In either case, please note the suggested policy change at https://fedorahosted.org/fesco/ticket/950 . Note that the first two paragraphs of the wiki page give general approval to starting certain kinds of services by default; it is not necessary to have a specific exception if your package matches the general approval criteria. Thank you, Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 6:34 PM, drago01 wrote:
> On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones wrote:
>> On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
>>> On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
>>> wrote:
>>> > On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote:
>>> >> > Basically: it's hard,
>>> >> it is a mess.
>>> >> > but the only way we're going to get to a
>>> >> > reasonably-small minimal image,
>>> >> not true.
>>> >
>>> > Given that the kernel is currently a full quarter of the current image, I
>>> > think it has to be.
>>>
>>> No you could also use a different kernel image;
>>> build your own kernel;
>>
>> [I'll treat these two the same, because they amount to the same thing]
>
> No the one means we ship a kernel-foo (like kernel-minimal or whatever
> we call it) and the other is you build your own kernel.
>
>> It's a considerable amount of work for everyone if people building
>> minimal images have to use a different kernel.
>
> If it is all about using kernel-minimal (or whatever it is called)
> instead of kernel there is no extra work for the ones that build
> minimal images at all.
>
>> By using the same kernel as everyone else, it means that bug reports
>> against the normal kernel package are relevant, and it means that the
>> regular kernel gets more testing.
>
> They can be built from the same srpm (same version, same patches
> applied just some modules stripped).
>
>> Also it's a lot of work to compile another kernel, when we've already
>> got a team of (apparently 3) people doing this.
>
> I'd argue it is less work then building a subpackage for every kernel module.
>
>>> use a compressed filesystem,
>>
>> Every minimal image I've ever seen has been compressed to the max.
>
> The image itself might be the installed system isn't ... which is the
> think I was talking about (i.e this would allow you to save disk space
> after installation).
> The smaller image would just save bandwidth for the initial download
> and/or space on mirrors.
>
>>> don't use a kernel at all and some
>>> container based approach instead of full virt for your cloud instances
>>
>> Unfortunately containers don't work for every application out there.
>> Obviously *if* you can use a container, then you should, and you
>> probably are already.
>
> That might be true but I can't think of such applications right now.
> Couldn't the applications you have in mind be modified / fixed to work
> in such an environment?
>
>>> Outside of the cloud use case the disk space added by modules and
>>> firmware does not matter a bit (so I am ignoring this cases).
>>
>> It's partly disk space, it's more often the time taken to copy these
>> images over the network (eg. when users download minimal images, or
>> when they are PXE-booted).
>
> In that case you should place the image on your internal network. I
> doubt anyone uses a cloud infrastructure where you download the images
> over the internet using a 56k modem.
>
>>> So there are lots of other ways to achieve what you want without
>>> splitting the kernel into hundreds of sub packages.
>>
>> I don't think we're talking "hundreds" of sub packages. Most people
>> seem to be discussing a split into between 2 and 5 packages.
>
> People where talking about splitting each module ("driver") into its
> own package. This are far more then 5.
Not necessarily, I was the person wanting it split down and only to
groups of packages like "usb" for usb devices, "arm" for arm only
firmware, "storage" for enterprise storage, "wifi" etc.
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, Oct 17, 2012 at 05:45:18PM +0200, Lennart Poettering wrote: > > b. All utilities should always work sensibly with grep (this is not the > >case on F18 right now) > Hmm? How so? Bug? Right now: https://bugzilla.redhat.com/show_bug.cgi?id=831665 Previously in systemctl: https://bugzilla.redhat.com/show_bug.cgi?id=626891 (I believe fixed.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes for today's FESCo meeting (2012-10-17)
=== #fedora-meeting: FESCO (2012-10-17) === Meeting started by mitr at 17:00:50 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-10-17/fesco.2012-10-17-17.00.log.html . Meeting summary --- * init process (mitr, 17:00:57) * #932 F18 Features - progress at Feature Freeze (mitr, 17:06:14) * #946 Fedora 18 Beta freeze readiness: is major functionality in place? (mitr, 17:08:52) * #950 Cleanup of the default enabled services list (mitr, 17:11:50) * AGREED: Will revisit when there is a list of specific changes (mitr, 17:17:30) * #958 Exception for updating ecj across major version boundary in f17 (mitr, 17:17:45) * AGREED: ecj major update in F17 is OK (+7) (mitr, 17:20:47) * #959 Mediation needed for cobbler in EPEL (mitr, 17:20:55) * AGREED: : Please ask epel-devel for a decision, and reopen a ticket if that doesn't lead to a resolution (+5) (mitr, 17:33:02) * Next week's chair (mitr, 17:33:09) * limburgher will chair the Oct 24 meeting (mitr, 17:34:47) * Open Floor (mitr, 17:34:52) Meeting ended at 17:38:21 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * mitr (48) * nirik (35) * limburgher (17) * t8m (10) * notting (10) * mmaslano (9) * zodbot (9) * vanaltj (8) * abadger1999 (6) * pjones (3) * mjg59 (0) * jwb (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting 2012-10-17
Good day all, This weeks Fedora ARM status meeting will take place today (Wednesday Oct 10th) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) F18/19 build status - problem packages? 2) Fedora 18 ARM TC1 VFAD - results summary 3) F18 ARM Alpha release 4) Your topic here If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 867267] perl-Encode-JP-Mobile-0.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=867267 --- Comment #3 from Fedora Update System --- Package perl-Encode-JP-Mobile-0.29-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Encode-JP-Mobile-0.29-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16326/perl-Encode-JP-Mobile-0.29-1.fc18 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones wrote:
> On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
>> On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
>> wrote:
>> > On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote:
>> >> > Basically: it's hard,
>> >> it is a mess.
>> >> > but the only way we're going to get to a
>> >> > reasonably-small minimal image,
>> >> not true.
>> >
>> > Given that the kernel is currently a full quarter of the current image, I
>> > think it has to be.
>>
>> No you could also use a different kernel image;
>> build your own kernel;
>
> [I'll treat these two the same, because they amount to the same thing]
No the one means we ship a kernel-foo (like kernel-minimal or whatever
we call it) and the other is you build your own kernel.
> It's a considerable amount of work for everyone if people building
> minimal images have to use a different kernel.
If it is all about using kernel-minimal (or whatever it is called)
instead of kernel there is no extra work for the ones that build
minimal images at all.
> By using the same kernel as everyone else, it means that bug reports
> against the normal kernel package are relevant, and it means that the
> regular kernel gets more testing.
They can be built from the same srpm (same version, same patches
applied just some modules stripped).
> Also it's a lot of work to compile another kernel, when we've already
> got a team of (apparently 3) people doing this.
I'd argue it is less work then building a subpackage for every kernel module.
>> use a compressed filesystem,
>
> Every minimal image I've ever seen has been compressed to the max.
The image itself might be the installed system isn't ... which is the
think I was talking about (i.e this would allow you to save disk space
after installation).
The smaller image would just save bandwidth for the initial download
and/or space on mirrors.
>> don't use a kernel at all and some
>> container based approach instead of full virt for your cloud instances
>
> Unfortunately containers don't work for every application out there.
> Obviously *if* you can use a container, then you should, and you
> probably are already.
That might be true but I can't think of such applications right now.
Couldn't the applications you have in mind be modified / fixed to work
in such an environment?
>> Outside of the cloud use case the disk space added by modules and
>> firmware does not matter a bit (so I am ignoring this cases).
>
> It's partly disk space, it's more often the time taken to copy these
> images over the network (eg. when users download minimal images, or
> when they are PXE-booted).
In that case you should place the image on your internal network. I
doubt anyone uses a cloud infrastructure where you download the images
over the internet using a 56k modem.
>> So there are lots of other ways to achieve what you want without
>> splitting the kernel into hundreds of sub packages.
>
> I don't think we're talking "hundreds" of sub packages. Most people
> seem to be discussing a split into between 2 and 5 packages.
People where talking about splitting each module ("driver") into its
own package. This are far more then 5.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
> From: Lennart Poettering > On Wed, 17.10.12 10:44, Matthew Miller (mat...@fedoraproject.org) wrote: > > b. All utilities should always work sensibly with grep (this is not the > >case on F18 right now) > > Hmm? How so? Bug? I see this as well. For example: # journalctl | head Logs begin at Wed, 17 Oct 2012 10:53:26 -0400, end at Wed, 17 Oct 2012 13:30:01 -0400. Oct 17 10:53:26 localhost systemd-journal[48]: Allowing runtime journal file Oct 17 10:53:26 localhost kernel: Initializing cgroup subsys cpuset Oct 17 10:53:26 localhost kernel: Initializing cgroup subsys cpu Oct 17 10:53:26 localhost kernel: Linux version 3.6.1-1.fc18.i686 (mockbuil...12 Oct 17 10:53:26 localhost kernel: e820: BIOS-provided physical RAM map: Oct 17 10:53:26 localhost kernel: BIOS-e820: [mem 0x-0x...le Oct 17 10:53:26 localhost kernel: BIOS-e820: [mem 0x0009e000-0x...ed Oct 17 10:53:26 localhost kernel: BIOS-e820: [mem 0x000f-0x...ed Oct 17 10:53:26 localhost kernel: BIOS-e820: [mem 0x0010-0x...le Adding the -a option prevents the truncation at around column 80, but it shouldn't be necessary. Seems like -a should be automatic if a pipe is involved. # rpm -qf $(which journalctl) systemd-194-1.fc18.i686 -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 4.00.1 is being uploaded (rawhide only)
On Wed, Oct 17, 2012 at 03:00:04PM +0100, Richard W.M. Jones wrote: > I don't think it is required to rebuild the packages in dependency > order this time, since no public interface has changed AFAICT. Actually we do, because the BR's cannot be installed in the build root until they themselves have been rebuilt. Possibly we can get around this (in future) by loosening the 'ocaml-runtime = ' dependency. That is really declaring that the *.cm* files contain a binary version number (Config.cm*_magic_number) which occasionally changes when the compiler is upgraded. It might be better, albeit harder, to encode those constants into the RPM dependencies instead. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On 10/17/2012 11:55 AM, Adam Williamson wrote: On Wed, 2012-10-17 at 16:05 +0200, Dario Lesca wrote: Il giorno mer, 17/10/2012 alle 08.37 -0500, David Lehman ha scritto: to keep you on your toes, of course you forgot ;-) ... because if you're talking seriously this is a wild unacceptable answer What is the real reason for this (for now unjustified) change? Does anyone know? Was the old one really better, or were you just used to it? Comparing the first time you use the new dialog to the 50th time you used the old one is an entirely unfair comparison. You have to compare the first time you use the new dialog to the first time you used the old one. *Any* new design will seem more difficult than the old one, at first, to someone who was familiar with the old one. I think the new dialog could use some improvements, and it's getting them, but a question like 'the old one ruled, the new one sucks, why u change?!' is really not that productive. The reasons for the UI re-design are in the feature page. The newui is akin to gnome 3 in that it takes some getting used to. Now, g3 is second nature and very usable. Using newui as much as possible, and filing bugs, helps a lot. My only gripe is that the storage portion of F17 worked very well at final and I only wish that logic had gone into F18 from alpha on. Why fight the storage battle again when it has already been won? -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On Wed, 2012-10-17 at 18:39 +0200, Miloslav Trmač wrote: > On Wed, Oct 17, 2012 at 6:29 PM, Stef Walter wrote: > > On 10/17/2012 06:21 PM, Miloslav Trmač wrote: > >> > >> That's rather far from actually fixing the problem. Can we get it > >> fixed_first_? It seems that we could drop the glibc caching, > > > > Obviously dropping the caching would be pretty nasty. Having to dlopen the > > modules each time you do a getpwnam() (or friends) isn't cool. > > > > I assume you mean fstating the file on each lookup? I'm not against this, > > and I can try and propose this to glibc, but I'm pretty sure what's going to > > happen. See similar /etc/resolv.conf discussions. > Yes, that's basically what I meant (perhaps only on each getXXnam() or > setXXent(), not on sequential getXXent() calls). > > >> I'm not opposed to changing the default nsswitch.conf to avoid that > >> reboot (well, I think it's ugly to refer to a non-installed module, > >> but that's an aesthetic, not a principal thing) and to improve the > >> user experience in the default case, but we do need to have some way > >> to fix the underlying problem, a better way than just giving up and > >> conceding that nsswitch.conf can't be edited from now on. > > > > > > We are working on it and I linked to that bug in my report. Ray Strode and I > > are working on patches to glibc. > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=12459 > > Right, this would still require a modification of every long-running > process dealing with the nsswitch databases. Modifying the glibc > caching behavior would probably be simpler. > > Jeff, what do you think? Personally I do not like the nss_init() calls, it will just make it even more difficult to diagnose 'heisenbugs' when some apps start doing it, some don't and some other do it at the wrong time. I would rather have glibc do it automatically with rate limiting. Like no more than once every 3 minutes do a stat on one of the getent calls and reload if necessary, still this would be thousands of unnecessary (vs 0 necessary) stat() calls every day, not the best solution. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, Oct 17, 2012 at 06:02:15PM +0100, Richard W.M. Jones wrote: > I'd like to see the current binary format officially documented > upstream, and a promise not maintain backwards compatibility forever Um ... promise TO maintain ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On Wed, 2012-10-17 at 18:29 +0200, Stef Walter wrote: > On 10/17/2012 06:21 PM, Miloslav Trmač wrote: > > That's rather far from actually fixing the problem. Can we get it > > fixed_first_? It seems that we could drop the glibc caching, > > Obviously dropping the caching would be pretty nasty. Having to dlopen > the modules each time you do a getpwnam() (or friends) isn't cool. > > I assume you mean fstating the file on each lookup? I'm not against > this, and I can try and propose this to glibc, but I'm pretty sure > what's going to happen. See similar /etc/resolv.conf discussions. This would kill perf. which is why it is not done. > > or by > > modify authconfig to instruct the user to reboot after changing > > /etc/nsswitch.conf . > > That's *really* ugly, and prevents tools (like ipa-client-install or > realmd) from completing an initialization in one shot. They would have > to be split into two parts, with a reboot in between. :S Yeah, extremely painful and unnecessary, please let's avoid this. > > I'm not opposed to changing the default nsswitch.conf to avoid that > > reboot (well, I think it's ugly to refer to a non-installed module, > > but that's an aesthetic, not a principal thing) and to improve the > > user experience in the default case, but we do need to have some way > > to fix the underlying problem, a better way than just giving up and > > conceding that nsswitch.conf can't be edited from now on. > > We are working on it and I linked to that bug in my report. Ray Strode > and I are working on patches to glibc. > > http://sourceware.org/bugzilla/show_bug.cgi?id=12459 > > Obviously, if you have another idea of how to fix this other than the > above, this would be a great place to put it forward. Long term I thin I can add support for the nscd protocol to sssd, it does work around this issue, but has other drawbacks which is why we haven;t done it so far. Stef can you open a ticket so we discuss and consider whether to do it ? This will take time however, in the meanwhile it would be really nice if we could do it the simple way by just adding sss by default until a better solution is found. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
I'd like to see the current binary format officially documented upstream, and a promise not maintain backwards compatibility forever (and some forwards compat too if possible). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote: > On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller > wrote: > > On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote: > >> > Basically: it's hard, > >> it is a mess. > >> > but the only way we're going to get to a > >> > reasonably-small minimal image, > >> not true. > > > > Given that the kernel is currently a full quarter of the current image, I > > think it has to be. > > No you could also use a different kernel image; > build your own kernel; [I'll treat these two the same, because they amount to the same thing] It's a considerable amount of work for everyone if people building minimal images have to use a different kernel. By using the same kernel as everyone else, it means that bug reports against the normal kernel package are relevant, and it means that the regular kernel gets more testing. Also it's a lot of work to compile another kernel, when we've already got a team of (apparently 3) people doing this. > use a compressed filesystem, Every minimal image I've ever seen has been compressed to the max. > don't use a kernel at all and some > container based approach instead of full virt for your cloud instances Unfortunately containers don't work for every application out there. Obviously *if* you can use a container, then you should, and you probably are already. > Outside of the cloud use case the disk space added by modules and > firmware does not matter a bit (so I am ignoring this cases). It's partly disk space, it's more often the time taken to copy these images over the network (eg. when users download minimal images, or when they are PXE-booted). > So there are lots of other ways to achieve what you want without > splitting the kernel into hundreds of sub packages. I don't think we're talking "hundreds" of sub packages. Most people seem to be discussing a split into between 2 and 5 packages. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 2012-10-17 at 17:45 +0200, Lennart Poettering wrote: > On Wed, 17.10.12 10:44, Matthew Miller (mat...@fedoraproject.org) wrote: > > > 2. Mechanism for separation of authpriv data > > Humm, so, I have my doubts that this really is desirable... > > "because syslog did it this way too" doesn't sound like a really good > reason for this. No you are getting it wrong here. It's not that syslog did it this way. But syslog was configured explicitly this way and on purpose, if it were logsys instead of syslog we'd still have the same configuration done by the maintainers of the distro. The point is that the authpriv target gets data from pam/login applications and it is *normal* to have leaked password sin there. So it should not be readable by anyone but root. Or a leaked password suddenly becomes a privilege escalation issue instead of just an annoyance. > I have my doubts that it really that much more > desirable to have this split off. If we really split this off (which > technically is easy to do), and nobody but root gets access to it, this > means that it will be *really* hard to see this stuff, and since it's > not that much data people will very likely never explicitly check for > it. It is supposed to be *really* hard because it is really sensitive. > I for one really would like to see these messages if I run > "journalctl" as user "lennart", who is in "wheel". I should get to see > these messages. But while I can see all other messages I wouldn't be > able to see authpriv, and there'd be no easy way to make them visible to > myself... Too bad. > Moreover, much of the information logged to authpriv is actually > available in utmp/wtmp afaics, so the I do wonder why have this at > all... No passwords in there, unless you happen to have a password that is incidentally also the name of a user. > So I am not convinced this is really that nice a feature. Effectively > this will have the effect that authpriv messages will end up being > invisible to admins -- and the data is too precious to hide it away like > this. It's no different than what we have today, I have yet to see *anyone* complaining and I work in Identity Management, authentication is my day to day job. > If we design the behaviour of these things we really need to focus on > getting the interesting data to the admin, and not raise pointless > stumbling blocks everywhere. And "syslog always did it that way" is a > really bad reason on its own... Please stop the 'syslog did it that way' strawman, the technology used has nothing to do with the policy enforced. It would have been supersimple to always pipe authpriv messages in to /var/log/messages if people wanted to. Instead they got in /var/log/secure because they are sensitive logs that are not supposed to be casually looked at by less privileged users, even staff users. > (I mean, maybe have this as an optional gimmick for the folks who > understand the split and know where to look makes sense, but i don't > think that this feature is really so superduper totally and utterly > necessary as a default, as you suggest...) It is superduper necessary by default, because you can't close the barn *after* the sheep have escaped. > > b. All utilities should always work sensibly with grep (this is not the > >case on F18 right now) > > Hmm? How so? Bug? > > > c. /var/log/messages written with a (syslog-formatted?) note pointing > >to journalctl (maybe even showing the new time-based filtering?) > > I'd much prefer adding /var/log/README instead, in order not to confuse > tools which assume a properly formatted log file in /var/log/messages. Good enough I guess. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, 17 Oct 2012, Dave Jones wrote: On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote: > > Given that the kernel is currently a full quarter of the current image, I > > think it has to be. > > No you could also use a different kernel image; build your own kernel; > use a compressed filesystem, don't use a kernel at all and some > container based approach instead of full virt for your cloud instances > (you could even base them on a btrfs subvolume and save more space > that way). > > Outside of the cloud use case the disk space added by modules and > firmware does not matter a bit (so I am ignoring this cases). > > So there are lots of other ways to achieve what you want without > splitting the kernel into hundreds of sub packages. So while it is a > way it is not "the only way". As reluctant as I am to introduce new kernel packages, an ultra-minimal kernel package for use in cloud environments may make more sense than splitting up the one-size-fits-all packages into hundreds of sub-packages. But even this option is a lot of work, and isn't a panacea. With virtualised environments supporting pci/usb passthrough, where do you draw the line on what hardware to support in a hypothetical kernel-cloud package ? You don't. More importantly I think the goal of shrinking the minimal install is a bad one. We're chasing a size that is better suited by custom spins or specific cloud installs. It should not be a goal of a distribution provider to crreate something custom tailored for a specific environment. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote: > > Given that the kernel is currently a full quarter of the current image, I > > think it has to be. > > No you could also use a different kernel image; build your own kernel; > use a compressed filesystem, don't use a kernel at all and some > container based approach instead of full virt for your cloud instances > (you could even base them on a btrfs subvolume and save more space > that way). > > Outside of the cloud use case the disk space added by modules and > firmware does not matter a bit (so I am ignoring this cases). > > So there are lots of other ways to achieve what you want without > splitting the kernel into hundreds of sub packages. So while it is a > way it is not "the only way". As reluctant as I am to introduce new kernel packages, an ultra-minimal kernel package for use in cloud environments may make more sense than splitting up the one-size-fits-all packages into hundreds of sub-packages. But even this option is a lot of work, and isn't a panacea. With virtualised environments supporting pci/usb passthrough, where do you draw the line on what hardware to support in a hypothetical kernel-cloud package ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On Wed, Oct 17, 2012 at 6:29 PM, Stef Walter wrote: > On 10/17/2012 06:21 PM, Miloslav Trmač wrote: >> >> That's rather far from actually fixing the problem. Can we get it >> fixed_first_? It seems that we could drop the glibc caching, > > Obviously dropping the caching would be pretty nasty. Having to dlopen the > modules each time you do a getpwnam() (or friends) isn't cool. > > I assume you mean fstating the file on each lookup? I'm not against this, > and I can try and propose this to glibc, but I'm pretty sure what's going to > happen. See similar /etc/resolv.conf discussions. Yes, that's basically what I meant (perhaps only on each getXXnam() or setXXent(), not on sequential getXXent() calls). >> I'm not opposed to changing the default nsswitch.conf to avoid that >> reboot (well, I think it's ugly to refer to a non-installed module, >> but that's an aesthetic, not a principal thing) and to improve the >> user experience in the default case, but we do need to have some way >> to fix the underlying problem, a better way than just giving up and >> conceding that nsswitch.conf can't be edited from now on. > > > We are working on it and I linked to that bug in my report. Ray Strode and I > are working on patches to glibc. > > http://sourceware.org/bugzilla/show_bug.cgi?id=12459 Right, this would still require a modification of every long-running process dealing with the nsswitch databases. Modifying the glibc caching behavior would probably be simpler. Jeff, what do you think? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 867297] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=867297 --- Comment #3 from Fedora Update System --- perl-Net-STOMP-Client-1.8-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Net-STOMP-Client-1.8-1.el6 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 867297] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=867297 --- Comment #2 from Fedora Update System --- perl-Net-STOMP-Client-1.8-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-Net-STOMP-Client-1.8-1.fc17 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 867297] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=867297 --- Comment #1 from Fedora Update System --- perl-Net-STOMP-Client-1.8-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-Net-STOMP-Client-1.8-1.el5 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F18 users unable to log in due to cached nsswitch.conf
On 10/17/2012 06:21 PM, Miloslav Trmač wrote: That's rather far from actually fixing the problem. Can we get it fixed_first_? It seems that we could drop the glibc caching, Obviously dropping the caching would be pretty nasty. Having to dlopen the modules each time you do a getpwnam() (or friends) isn't cool. I assume you mean fstating the file on each lookup? I'm not against this, and I can try and propose this to glibc, but I'm pretty sure what's going to happen. See similar /etc/resolv.conf discussions. or by modify authconfig to instruct the user to reboot after changing /etc/nsswitch.conf . That's *really* ugly, and prevents tools (like ipa-client-install or realmd) from completing an initialization in one shot. They would have to be split into two parts, with a reboot in between. :S I'm not opposed to changing the default nsswitch.conf to avoid that reboot (well, I think it's ugly to refer to a non-installed module, but that's an aesthetic, not a principal thing) and to improve the user experience in the default case, but we do need to have some way to fix the underlying problem, a better way than just giving up and conceding that nsswitch.conf can't be edited from now on. We are working on it and I linked to that bug in my report. Ray Strode and I are working on patches to glibc. http://sourceware.org/bugzilla/show_bug.cgi?id=12459 Obviously, if you have another idea of how to fix this other than the above, this would be a great place to put it forward. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On Wed, Oct 17, 2012 at 5:17 PM, Stef Walter wrote: > In Fedora 17 and 18 we have a problem where remote users are unable to log > in until the machine has been rebooted. This used to work previously. To fix > this we probably need to: > > Include 'sss' in /etc/nsswitch.conf by default and have the small > sssd-client package (with just thepam, nss plugins) installed on all but > minimal Fedora installs. That's rather far from actually fixing the problem. Can we get it fixed _first_? It seems that we could drop the glibc caching, or by modify authconfig to instruct the user to reboot after changing /etc/nsswitch.conf . I'm not opposed to changing the default nsswitch.conf to avoid that reboot (well, I think it's ugly to refer to a non-installed module, but that's an aesthetic, not a principal thing) and to improve the user experience in the default case, but we do need to have some way to fix the underlying problem, a better way than just giving up and conceding that nsswitch.conf can't be edited from now on. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-STOMP-Client/f18] New upstream 1.8, rhbz#867297.
Summary of changes: 5fc89cf... New upstream 1.8, rhbz#867297. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-STOMP-Client/f17] New upstream 1.8, rhbz#867297.
Summary of changes: 5fc89cf... New upstream 1.8, rhbz#867297. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-STOMP-Client/f16] New upstream 1.8, rhbz#867297.
Summary of changes: 5fc89cf... New upstream 1.8, rhbz#867297. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-STOMP-Client/el6: 2/2] Merge branch 'master' into el6
commit 2ecc6de5ee17bcf8db6e10deda5fe1669ffc10d8 Merge: a7f6f77 5fc89cf Author: Massimo Date: Wed Oct 17 18:17:42 2012 +0200 Merge branch 'master' into el6 .gitignore |1 + perl-Net-STOMP-Client.spec |5 - sources|2 +- 3 files changed, 6 insertions(+), 2 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-STOMP-Client/el6] (2 commits) ...Merge branch 'master' into el6
Summary of changes: 5fc89cf... New upstream 1.8, rhbz#867297. (*) 2ecc6de... Merge branch 'master' into el6 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-STOMP-Client/el5: 2/2] Merge branch 'master' into el5
commit e17c1b541f9576e6cc235b9e0eaca9b57e793427 Merge: 9c7543e 5fc89cf Author: Massimo Date: Wed Oct 17 18:17:52 2012 +0200 Merge branch 'master' into el5 .gitignore |1 + perl-Net-STOMP-Client.spec |5 - sources|2 +- 3 files changed, 6 insertions(+), 2 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-STOMP-Client/el5] (2 commits) ...Merge branch 'master' into el5
Summary of changes: 5fc89cf... New upstream 1.8, rhbz#867297. (*) e17c1b5... Merge branch 'master' into el5 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: What are reasonable blockers for making journald the default logger in F19?
On 10/17/2012 03:50 PM, Lennart Poettering wrote: the files are stored in /var/log/journal/ Is it not better to place this under /var/journal/ and leave text files to /var/log/ to prevent administrators thinking they can treat the journal files a text files and prevent any kind of script breakage that expect all files in that directory to be text files? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-STOMP-Client] New upstream 1.8, rhbz#867297.
commit 5fc89cf88c6757b9afb97054f1233304aed46b0e
Author: Massimo
Date: Wed Oct 17 18:04:45 2012 +0200
New upstream 1.8, rhbz#867297.
.gitignore |1 +
perl-Net-STOMP-Client.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f72e512..71d049c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ Net-STOMP-Client-0.9.2.tar.gz
/Net-STOMP-Client-1.4.tar.gz
/Net-STOMP-Client-1.5.tar.gz
/Net-STOMP-Client-1.7.tar.gz
+/Net-STOMP-Client-1.8.tar.gz
diff --git a/perl-Net-STOMP-Client.spec b/perl-Net-STOMP-Client.spec
index 49c7abb..7fd8152 100644
--- a/perl-Net-STOMP-Client.spec
+++ b/perl-Net-STOMP-Client.spec
@@ -1,5 +1,5 @@
Name: perl-Net-STOMP-Client
-Version:1.7
+Version:1.8
Release:1%{?dist}
Summary:STOMP object oriented client module
License:GPL+ or Artistic
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Aug 6 2012 Massimo Paladin - 1.8-1
+- New upstream 1.8, rhbz#867297.
+
* Mon Aug 6 2012 Steve Traylen - 1.7-1
- New upstream 1.7, rhbz#837746.
diff --git a/sources b/sources
index e0a0f47..2f70a61 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-58a2b954700335621043026e7f759bea Net-STOMP-Client-1.7.tar.gz
+3d1d6d3ed3cfe1f2806374ddb7a0590f Net-STOMP-Client-1.8.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Net-STOMP-Client-1.8.tar.gz uploaded to lookaside cache by mpaladin
A file has been added to the lookaside cache for perl-Net-STOMP-Client: 3d1d6d3ed3cfe1f2806374ddb7a0590f Net-STOMP-Client-1.8.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 867297] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=867297 Steve Traylen changed: What|Removed |Added Status|NEW |ASSIGNED QA Contact|extras...@fedoraproject.org |steve.tray...@cern.ch -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller wrote: > On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote: >> > Basically: it's hard, >> it is a mess. >> > but the only way we're going to get to a >> > reasonably-small minimal image, >> not true. > > Given that the kernel is currently a full quarter of the current image, I > think it has to be. No you could also use a different kernel image; build your own kernel; use a compressed filesystem, don't use a kernel at all and some container based approach instead of full virt for your cloud instances (you could even base them on a btrfs subvolume and save more space that way). Outside of the cloud use case the disk space added by modules and firmware does not matter a bit (so I am ignoring this cases). So there are lots of other ways to achieve what you want without splitting the kernel into hundreds of sub packages. So while it is a way it is not "the only way". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Wed, 2012-10-17 at 10:49 +0200, Vít Ondruch wrote: > Dne 16.10.2012 18:06, Jesse Keating napsal(a): > > On 10/16/2012 08:53 AM, Dario Lesca wrote: > >> If this feature is not included then you can not update F1[0-7] on > >> systems that have used LVM / RAID: all my PCs and laptops. > > > > Anaconda no longer handles upgrades, so this isn't a concern. > > > > Oh come on. I have LVM and luks on my system with different versions of > Fedora. I want to install Fedora into newly created partitions, but I > can't, since Anaconda does not display the LVM volume label, so I don't > know what is what, nor let me unlock luks partition. > > Upgrade would be if I want to move from my F17 to F18, but I want to > install them side by side (which is not upgrade) and that is not possible. I think this is going in the wrong direction. The whole discussion was based on a false premise: newUI does intend to handle LUKS, LVM and RAID. Where it doesn't read and display an existing LUKS, LVM and/or RAID-based layout correctly/usefully this is a bug, please report it as such. Those earlier in the thread who leapt to the conclusion that anaconda did not handle these things any more were *incorrect*. Jesse, above, is only saying that upgrades no longer go through anaconda, so any upgrade-related concerns are irrelevant. But for the purposes of fresh installs, newUI is intended to handle the creation of new LUKS/LVM/RAID devices and the display and editing of existing ones. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Wed, 2012-10-17 at 16:05 +0200, Dario Lesca wrote: > Il giorno mer, 17/10/2012 alle 08.37 -0500, David Lehman ha scritto: > > to keep you on your toes, of course > > you forgot ;-) ... because if you're talking seriously this is a wild > unacceptable answer > > What is the real reason for this (for now unjustified) change? > > Does anyone know? Was the old one really better, or were you just used to it? Comparing the first time you use the new dialog to the 50th time you used the old one is an entirely unfair comparison. You have to compare the first time you use the new dialog to the first time you used the old one. *Any* new design will seem more difficult than the old one, at first, to someone who was familiar with the old one. I think the new dialog could use some improvements, and it's getting them, but a question like 'the old one ruled, the new one sucks, why u change?!' is really not that productive. The reasons for the UI re-design are in the feature page. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 17.10.12 11:04, Simo Sorce (s...@redhat.com) wrote: > I was wondering if /var/log/messages could be turned into a named pipe > to which journal start spitting out stuff in syslog format when someone > tails it ? Named pipes are single-reader streams. Also, for if they run full the newest data is dropped, not the oldest, hence they are quite unsuitable for a purpose like this. I think it is a much better idea to make it easy for people to discover the new tools (i.e. README file in /var/log) rather then trying to emulate the old behaviour with pipes or cuse, which will necessarily be incomplete and only working half-way. Especially given that people can easily get their log files back, simply by installing syslog-ng/rsyslog. > just a wild idea (and can be any other file name in /var/log as long as > it is easily discoverable and doesn't cause issues to existing utilities > that crawl /var/log), but I would strongly miss being able to tail logs > with my pipeline that does coloring etc ... (Side note: you get priority-based coloring in journalctl by default). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 867297] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=867297 Massimo Paladin changed: What|Removed |Added Assignee|steve.tray...@cern.ch |massimo.pala...@gmail.com -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 17.10.12 17:07, Benny Amorsen (benny+use...@amorsen.dk) wrote: > Matthew Miller writes: > > > Less critical but important: > > A hard link to an easier-to-guess name like logread (used by OpenWRT)? Instead of introducing new aliases and ambiguities by introducing yet another name that has no relation to the subsystem otherwise (afterall, the server-side is called journald, the files are stored in /var/log/journal/ and have the suffix .journal, and so on) we should really focus on making it easy to discover the new tool, under its right name. One way to achieve that should be to provide /var/log/README with the appropriate hints, since I assume much more people will look for logs in /var/log like it used to be in most of Linux history rather than in a tool "logread" that is known by an embedded distro by the name of OpenWRT... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 11:37:29AM -0400, Josh Boyer wrote: > What the hell did you drink today, Bill? Basically what you're > suggesting is that Fedora move to a kmod model for everything. Which > means you'd have to install all of them by default anyway or the kernel > team would be swamped with bugs like "I installed Fedora and my random > USB device doesn't work!" The default desktop case would pull in everything, I think. Splitting it up would be not just for fun but in order to target smaller cloud and virt images. Because we can reasonably define the targets there, it doesn't need to be completely all-out "kmod model for everything" approach at all. > Seriously, no. There are 3 kernel people. There's no way we have time > to sit around closing bugs with stuff like "Install kernel-module-foo". Yeah; it is reasonable to say that we can't do this without more resources. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote: > > Basically: it's hard, > it is a mess. > > but the only way we're going to get to a > > reasonably-small minimal image, > not true. Given that the kernel is currently a full quarter of the current image, I think it has to be. > > so if that's important (and I believe it > > is), > I believe it isn't. And that's fine. We'll need to come to a group decision eventually but we don't need to right now. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 17.10.12 10:44, Matthew Miller (mat...@fedoraproject.org) wrote: > 2. Mechanism for separation of authpriv data Humm, so, I have my doubts that this really is desirable... "because syslog did it this way too" doesn't sound like a really good reason for this. I have my doubts that it really that much more desirable to have this split off. If we really split this off (which technically is easy to do), and nobody but root gets access to it, this means that it will be *really* hard to see this stuff, and since it's not that much data people will very likely never explicitly check for it. I for one really would like to see these messages if I run "journalctl" as user "lennart", who is in "wheel". I should get to see these messages. But while I can see all other messages I wouldn't be able to see authpriv, and there'd be no easy way to make them visible to myself... Moreover, much of the information logged to authpriv is actually available in utmp/wtmp afaics, so the I do wonder why have this at all... So I am not convinced this is really that nice a feature. Effectively this will have the effect that authpriv messages will end up being invisible to admins -- and the data is too precious to hide it away like this. If we design the behaviour of these things we really need to focus on getting the interesting data to the admin, and not raise pointless stumbling blocks everywhere. And "syslog always did it that way" is a really bad reason on its own... (I mean, maybe have this as an optional gimmick for the folks who understand the split and know where to look makes sense, but i don't think that this feature is really so superduper totally and utterly necessary as a default, as you suggest...) > b. All utilities should always work sensibly with grep (this is not the >case on F18 right now) Hmm? How so? Bug? > c. /var/log/messages written with a (syslog-formatted?) note pointing >to journalctl (maybe even showing the new time-based filtering?) I'd much prefer adding /var/log/README instead, in order not to confuse tools which assume a properly formatted log file in /var/log/messages. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Once upon a time, Matthew Miller said: > a. Use wheel group in addition to adm -- work with the way Fedora/RHEL >currently do things As others have pointed out, Fedora/RHEL don't currently set logs to readable by anyone other than root. However, I think it is a good idea to allow privileged non-root users to read logs (I set my systems up with logs group-readable and owned by wheel). However, IMHO this should be configurable, not hard-coded into systemd (hard-coding things like this is almost always a bad idea). It would be nice to allow some finer-grained controls (again, on some of my systems, some logs are readable by different groups, sometimes more than one via file ACLs). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 4:51 PM, Matthew Miller wrote: > On Wed, Oct 17, 2012 at 10:47:34AM -0400, Bill Nottingham wrote: >>> If you're suggesting 1, I'd be really really opposed to that. It would >>> make packaging in kernel.spec even more of a nightmare than it already >>> is. > [...] >> Both - if people want firmware packages split out of linux-firmware, it >> doesn't make sense unless the drivers (similar in size) are also split, >> and if you were to do so, you'd need to start adding the driver -> firmware >> package dependency mapping. > > Basically: it's hard, it is a mess. > but the only way we're going to get to a > reasonably-small minimal image, not true. > so if that's important (and I believe it > is), I believe it isn't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 10:51 AM, Matthew Miller wrote: > On Wed, Oct 17, 2012 at 10:47:34AM -0400, Bill Nottingham wrote: >>> If you're suggesting 1, I'd be really really opposed to that. It would >>> make packaging in kernel.spec even more of a nightmare than it already >>> is. > [...] >> Both - if people want firmware packages split out of linux-firmware, it >> doesn't make sense unless the drivers (similar in size) are also split, >> and if you were to do so, you'd need to start adding the driver -> firmware >> package dependency mapping. What the hell did you drink today, Bill? Basically what you're suggesting is that Fedora move to a kmod model for everything. Which means you'd have to install all of them by default anyway or the kernel team would be swamped with bugs like "I installed Fedora and my random USB device doesn't work!" Seriously, no. There are 3 kernel people. There's no way we have time to sit around closing bugs with stuff like "Install kernel-module-foo". > Basically: it's hard, but the only way we're going to get to a > reasonably-small minimal image, so if that's important (and I believe it > is), it's something Fedora should invest resources in. No. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora-r-devel-list] Building RPMs for Fedora with circular "suggest" dependencies
On 06/15/2012 02:25 PM, William Emmanuel S. Yu wrote: > Hi Allen, > > Thanks for the quick reply. > > I actually encountered this point of yours and that is why I found this > mailing list. > > On your solution, I did try putting 'export _R_CHECK_FORCE_SUGGESTS_ = false; > R CMD check' in the spec file. But now, it fails again again doing a test > that requires foreach while building iterator. > > Thanks again. > "Sent via BlackBerry from Smart" Hi, have you been able to proceed here? I suppose that the only real option is to proceed in several steps in a kind of bootstrapping setup, first ignoring the suggests and the checks and on a second round adding those back. Probably this is easier said then done. :-) Regards, -- José Matos ___ r-devel mailing list r-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/r-devel
Re: F18 users unable to log in due to cached nsswitch.conf
On Wed, 2012-10-17 at 11:21 -0400, Simo Sorce wrote: > On Wed, 2012-10-17 at 17:17 +0200, Stef Walter wrote: > > In Fedora 17 and 18 we have a problem where remote users are unable to > > log in until the machine has been rebooted. This used to work > > previously. To fix this we probably need to: > > > > Include 'sss' in /etc/nsswitch.conf by default and have the small > > sssd-client package (with just thepam, nss plugins) installed on all but > > minimal Fedora installs. > > > > Is it too late to do this for Fedora 18? I'd jump in and provide the > > patches necessary. Sadly it's been hard to test a coherent system up > > until this point, so I thought this was a fluke of my test F18 systems > > until just the other day. > > > > Cheers, > > > > Stef > > I want to add, that having the 'sss' line in nsswitch.conf is completely > harmless both if the libnss_sss plugin is not available (minimal) and if > it is available but sssd is not. > The library has been built to be resilient and not block or cause issues > when the daemon is present. glibc also just ignores missing plugins. and I meant 'missing' here ^^ of course ... > So adding that line by default in nsswitch.conf should have no > unintended consequences or bad failure modes. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 users unable to log in due to cached nsswitch.conf
On Wed, 2012-10-17 at 17:17 +0200, Stef Walter wrote: > In Fedora 17 and 18 we have a problem where remote users are unable to > log in until the machine has been rebooted. This used to work > previously. To fix this we probably need to: > > Include 'sss' in /etc/nsswitch.conf by default and have the small > sssd-client package (with just thepam, nss plugins) installed on all but > minimal Fedora installs. > > Is it too late to do this for Fedora 18? I'd jump in and provide the > patches necessary. Sadly it's been hard to test a coherent system up > until this point, so I thought this was a fluke of my test F18 systems > until just the other day. > > Cheers, > > Stef I want to add, that having the 'sss' line in nsswitch.conf is completely harmless both if the libnss_sss plugin is not available (minimal) and if it is available but sssd is not. The library has been built to be resilient and not block or cause issues when the daemon is present. glibc also just ignores missing plugins. So adding that line by default in nsswitch.conf should have no unintended consequences or bad failure modes. Simo. > > > DETAILS: > > This happens after configuration using authconfig to change > /etc/nsswitch.conf (or doing it manually). The changes are not picked up > by long running processes like dbus-daemon --system. As far as I can see > dbus-daemon then refuses to allow connections from these users. As might > be expected, gnome-shell crashes hard when this happens. > > There are some other ways to fix this problem, but these do not scale to > fix the problem for every possible affected process: > > http://sourceware.org/bugzilla/show_bug.cgi?id=12459 > > Below I have a rough test for duplicating the problem. > > > TEST CASE: > > * This should be ideally run on a freshly installed system or at >least a system without sss in /etc/nsswitch.conf since last boot. > > $ grep sss /etc/nsswitch.conf && "ALREADY HAVE sss" > $ sudo -s > # yum install sssd-tools pamtester > # test -f /etc/sssd/sssd.conf && mv /etc/sssd/sssd.conf > /etc/sssd/sssd.conf.bak > # echo -e > "[sssd]\ndomains=local\nconfig_file_version=2\nservices=nss,pam\n[domain/local]\nid_provider=local" > > > /etc/sssd/sssd.conf > # chmod 0600 /etc/sssd/sssd.conf > # systemctl start sssd.service > # authconfig --update --enablesssd --enablesssdauth > # sss_useradd --uid=2121 --gecos=Zapp zapp > # passwd zapp # set password for zapp > # pamtester zapp authenticate # type password, should succeed > > * Now go to gdm by logging out or switch user. > * Try to log in as zapp. > * Hang. > * Reboot > * Try to log in as zapp. > * Success > > > TRACKER BUG: https://bugzilla.redhat.com/show_bug.cgi?id=867473 > > > Cheers, > > Stef > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F18 users unable to log in due to cached nsswitch.conf
In Fedora 17 and 18 we have a problem where remote users are unable to log in until the machine has been rebooted. This used to work previously. To fix this we probably need to: Include 'sss' in /etc/nsswitch.conf by default and have the small sssd-client package (with just thepam, nss plugins) installed on all but minimal Fedora installs. Is it too late to do this for Fedora 18? I'd jump in and provide the patches necessary. Sadly it's been hard to test a coherent system up until this point, so I thought this was a fluke of my test F18 systems until just the other day. Cheers, Stef DETAILS: This happens after configuration using authconfig to change /etc/nsswitch.conf (or doing it manually). The changes are not picked up by long running processes like dbus-daemon --system. As far as I can see dbus-daemon then refuses to allow connections from these users. As might be expected, gnome-shell crashes hard when this happens. There are some other ways to fix this problem, but these do not scale to fix the problem for every possible affected process: http://sourceware.org/bugzilla/show_bug.cgi?id=12459 Below I have a rough test for duplicating the problem. TEST CASE: * This should be ideally run on a freshly installed system or at least a system without sss in /etc/nsswitch.conf since last boot. $ grep sss /etc/nsswitch.conf && "ALREADY HAVE sss" $ sudo -s # yum install sssd-tools pamtester # test -f /etc/sssd/sssd.conf && mv /etc/sssd/sssd.conf /etc/sssd/sssd.conf.bak # echo -e "[sssd]\ndomains=local\nconfig_file_version=2\nservices=nss,pam\n[domain/local]\nid_provider=local" > /etc/sssd/sssd.conf # chmod 0600 /etc/sssd/sssd.conf # systemctl start sssd.service # authconfig --update --enablesssd --enablesssdauth # sss_useradd --uid=2121 --gecos=Zapp zapp # passwd zapp # set password for zapp # pamtester zapp authenticate # type password, should succeed * Now go to gdm by logging out or switch user. * Try to log in as zapp. * Hang. * Reboot * Try to log in as zapp. * Success TRACKER BUG: https://bugzilla.redhat.com/show_bug.cgi?id=867473 Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
Matthew Miller writes: > Less critical but important: A hard link to an easier-to-guess name like logread (used by OpenWRT)? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are reasonable blockers for making journald the default logger in F19?
On Wed, 2012-10-17 at 10:44 -0400, Matthew Miller wrote: > With the stipulation that rsyslog would still be available to provide a > traditional syslog-style text logs, what are reasonable hard requirements > for making systemd the main logging system installed by default? (Or, an > alternate softer implementation: rsyslogd would be installed by default but > would not be in 'core'.) > > These are the things I think are critical: > > 1. Time based rotation policies (implementation landing now.) ack > 2. Mechanism for separation of authpriv data I think authpriv should be separate by default in Fedora. > 3. Disk-based storage on by default (ie /var/log/journal exists) ack > 4. Traditional syslog still easily available via rsyslogd ack > 5. Journal format documented ack, documented and a promise to not change it arbitrarily (should be easy because the format has already been though to work that way) > 6. Strong QA exploring corner cases and data corruption (procedure tbd) > 7. Clear, simple, and Fedora-centric disaster recovery documentation I am not sure 6/7 are strong requisites. We certainly shipped stuff that was hard to deal with when it broke before. I would love to see this done for F19 but I think it would be unfair to block the feature just on point 6/7 unless there is a significant higher risk of issues with the journal than there ever was with malfunctioning (r)syslog. Is your worry that because the journal file is a binary format and not a plain text file that corruption of the journal files is more likely / more problematic ? > Less critical but important: > > a. Use wheel group in addition to adm -- work with the way Fedora/RHEL >currently do things > b. All utilities should always work sensibly with grep (this is not the >case on F18 right now) I think I would elevate this to blocker status instead. > c. /var/log/messages written with a (syslog-formatted?) note pointing >to journalctl (maybe even showing the new time-based filtering?) I was wondering if /var/log/messages could be turned into a named pipe to which journal start spitting out stuff in syslog format when someone tails it ? just a wild idea (and can be any other file name in /var/log as long as it is easily discoverable and doesn't cause issues to existing utilities that crawl /var/log), but I would strongly miss being able to tail logs with my pipeline that does coloring etc ... > And, in order for the implementation to really be a *win* for Fedora, it > would be great if we could coordinate: > > - integration with every log analysis tool tool we ship (for some tools, > a crude implementation may just be dumping in the output of journalctl, > using a temp file as worst case) > > - integration with every monitoring system where it make sense > > - bonus points: make these integrations benefit from systemd's fancy > features. > > Are these reasonable? Are there other important things I'm missing? The plan sounds very reasonable in general. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-List-MoreUtils] Created tag perl-List-MoreUtils-0.33-7.fc19
The lightweight tag 'perl-List-MoreUtils-0.33-7.fc19' was created pointing to: d8d9392... Spec clean-up -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: OCaml 4.00.1 is being uploaded (rawhide only)
On Tue, Oct 16, 2012 at 07:27:43PM +0100, Richard W.M. Jones wrote: > > This is not a major change, but things may be broken in > Rawhide briefly ... That's gone in, and there are a number of broken OCaml packages as a result. You can help! For each package: (1) Check if there is a new upstream version. (2) If NO new upstream version, just bump the release number and rebuild the package. I don't think it is required to rebuild the packages in dependency order this time, since no public interface has changed AFAICT. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 10:47:34AM -0400, Bill Nottingham wrote: >> If you're suggesting 1, I'd be really really opposed to that. It would >> make packaging in kernel.spec even more of a nightmare than it already >> is. [...] > Both - if people want firmware packages split out of linux-firmware, it > doesn't make sense unless the drivers (similar in size) are also split, > and if you were to do so, you'd need to start adding the driver -> firmware > package dependency mapping. Basically: it's hard, but the only way we're going to get to a reasonably-small minimal image, so if that's important (and I believe it is), it's something Fedora should invest resources in. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Josh Boyer (jwbo...@gmail.com) said: > > However, if you go down that route, the kernel should be the same way, > > the firmware should be separate subpackages, and requires should be done at > > the module -> firmware level by generating it from the MODULE_FIRMWARE tags. > > (Unless you're relying on packagekit to install your firmware, which if > > you're going that minimal seems to have missed the forest for the trees > > somewhere.) > > I'm not understanding what you're proposing. Are you suggesting: > > 1) We have further split up module sub-packages that carry their own > firmware requires (e.g. kernel-module-iwlwifi requires iwlwifi-firmware) > > or > > 2) Even more firmware subpackages split out of linux-firmware. > > If you're suggesting 1, I'd be really really opposed to that. It would > make packaging in kernel.spec even more of a nightmare than it already > is. > > If you're suggesting 2, I don't see the point. The kernel will install > and even with per-module dependencies generated (somehow), it'll still > install all of the various -firmware packages because the modules will > be getting installed. Both - if people want firmware packages split out of linux-firmware, it doesn't make sense unless the drivers (similar in size) are also split, and if you were to do so, you'd need to start adding the driver -> firmware package dependency mapping. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What are reasonable blockers for making journald the default logger in F19?
With the stipulation that rsyslog would still be available to provide a traditional syslog-style text logs, what are reasonable hard requirements for making systemd the main logging system installed by default? (Or, an alternate softer implementation: rsyslogd would be installed by default but would not be in 'core'.) These are the things I think are critical: 1. Time based rotation policies (implementation landing now.) 2. Mechanism for separation of authpriv data 3. Disk-based storage on by default (ie /var/log/journal exists) 4. Traditional syslog still easily available via rsyslogd 5. Journal format documented 6. Strong QA exploring corner cases and data corruption (procedure tbd) 7. Clear, simple, and Fedora-centric disaster recovery documentation Less critical but important: a. Use wheel group in addition to adm -- work with the way Fedora/RHEL currently do things b. All utilities should always work sensibly with grep (this is not the case on F18 right now) c. /var/log/messages written with a (syslog-formatted?) note pointing to journalctl (maybe even showing the new time-based filtering?) And, in order for the implementation to really be a *win* for Fedora, it would be great if we could coordinate: - integration with every log analysis tool tool we ship (for some tools, a crude implementation may just be dumping in the output of journalctl, using a temp file as worst case) - integration with every monitoring system where it make sense - bonus points: make these integrations benefit from systemd's fancy features. Are these reasonable? Are there other important things I'm missing? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: Saitek Pro Flight controls refuse to operate with kernel 3.6.1 upgrade
On 10/16/2012 05:41 PM, Gerry Reno wrote: > I just found another problem with the upgrade to kernel 3.6.1 > > My Saitek Pro Flight controls (yoke and pedals) refuse to operate now. > > I can see them in dmesg but they do nothing when running FlightGear now. > > Solved by updating kernel-modules-extra. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, Oct 17, 2012 at 02:13:35PM +0200, Lennart Poettering wrote: > This is implemented now, but I called it --since= and --until=. I'll > push this into F18 as well, sicne it's actually a minor change only, and > just too useful. Thanks Lennart. This is great stuff. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
Il giorno mer, 17/10/2012 alle 08.37 -0500, David Lehman ha scritto: > to keep you on your toes, of course you forgot ;-) ... because if you're talking seriously this is a wild unacceptable answer What is the real reason for this (for now unjustified) change? Does anyone know? -- Dario Lesca - sip:da...@solinos.it (Inviato dal mio Linux Fedora 17 Gnome3) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Wed, 2012-10-17 at 14:28 +0200, Richard Marko wrote: > Previous structured partitioning dialog was much better compared to > this. Why > it was removed in favor of this confusing thing? to keep you on your toes, of course -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121017 changes
Compose started at Wed Oct 17 09:15:20 UTC 2012 Broken deps for x86_64 -- [almanah] almanah-0.8.0-7.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libecal-1.2.so.12()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libebook-1.2.so.13()(64bit) [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dustmite] dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires libphobos-ldc.so.59()(64bit) [epiphany-extensions] epiphany-extensions-3.5.0-0.2.20120914gitf4fcbfc.fc18.x86_64 requires epiphany(abi) = 0:3.5 [evolution-exchange] evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-cal-1.2.so.17()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-book-1.2.so.14()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libecal-1.2.so.12()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebackend-1.2.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libcamel-1.2.so.36()(64bit) [fedmsg] fedmsg-0.5.4-4.fc18.noarch requires python-moksha-hub >= 0:1.0.1 [flush] flush-0.9.10-7.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_signals-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [func] func-0.28-1.fc17.noarch requires smolt [gcc-python-plugin] gcc-python2-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python2-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-debug-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 gcc-python3-plugin-0.9-5.fc18.x86_64 requires gcc = 0:4.7.2-2.fc18 [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [glom] glom-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) glom-libs-1.18.6-1.fc17.i686 requires libboost_python.so.1.48.0 glom-libs-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-10.fc18.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.4.0.0 [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserver-1.2.so.16()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libebook-1.2.so.13()(64bit) [gnome-shell-theme-selene] gnome-shell-theme-selene-3.4.0-5.fc18.noarch requires gnome-shell-extensions-user-theme [gwibber] 1:gwibber-3.4.2-3.fc18.i686 requires libgee-0.8.so.0 1:gwibber-3.4.2-3.fc18.x86_64 requires libgee-0.8.so.0()(64bit) [ip-sentinel] ip-sentinel-upstart-0.12-1303.fc18.noarch requires /sbin/initctl [ktp-call-ui] ktp-call-ui-0.5.1-1.fc18.x86_64 requires libtelepathy-farstream.so.2()(64bit) [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [maniadrive] raydium-1.2-47.fc18.x86_64 requires libode.so.1()(64bit) [mapserver] mapserver-perl-6.0.1-5.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [milter-greylist] milter-greylist-upstart-4.2.7-1701.fc18.noarch requires /sbin/initctl [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [openvrml] libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_sys
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Tue, 09.10.12 23:24, Lennart Poettering (mzerq...@0pointer.de) wrote: > I am not generally against adding time-based rotation, but really, this > is much less of a "necessity" than other things the journal provides, > which syslog does not: for example per-service rate limits, and > unfakable meta-data for log messages. I mean, really, how can we ship > a syslog where every random user can fake messages, say they are from a > privileged process and offer no way how to detect that? To settle this discussion as well I've now implemented time-based rotation for the journal as well, and this will also hit F18 soonishly. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
