Re: F20 Self Contained Change: Ruby on Rails 4.0
Dne 15.7.2013 18:31, Bill Nottingham napsal(a): Jaroslav Reznik (jrez...@redhat.com) said: = Proposed Self Contained Change: Ruby on Rails 4.0 = https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0 Change owner(s): Vít Ondruch , Josef Stříbný , ruby-...@lists.fedoraproject.org Ruby on Rails 4.0 is the latest version of well know web framework written in Ruby. == Detailed description == The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with it. Therefore the whole Ruby on Rails stack should be updated from 3.2 in Fedora 19 to 4.0 (latest version) in Fedora 20. This will ensure that all the Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on Rails. == Scope == Proposal owners: * The whole Rails stack has to be updated * New additional gems will have to be packaged * Some dependencies of the Rails stack will need update Does this work for users of Rails currently in Fedora, or will those packages need upgraded/ported as well? Bill There is plenty of rubygem-*-rails packages in Fedora. We will try to ensure, that all these works. There is currently no Rails application in Fedora to my knowledge. Nevertheless, some functionality previously available in Rails was deprecated and extracted into separate gems. Not sure if it is worth of importing all these packages into Fedora, since the code is considered legacy by RoR upstream. Therefore, there is chance that application using RoR on F19 will *not* survive upgrade to F20 without modifications. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
- Original Message - > On Mon, Jul 15, 2013 at 02:46:27PM -0600, Eric Smith wrote: > > I don't actually care whether there's a binary journal or not, but far > > more of us have real usecases for /var/log/messages, so we shouldn't > > give up that being available by default. > > If you use bash or ksh you could just replace /var/log/messages with > <(journalctl) in your command line and stuff should just work (when > reading). Other shells can probably do the same. It obviously depends on > journalctl being able to run. And you want to do the system wide search and replace all the 3rd party programs, scripts, and documents that mentioned /var/log/messages? Even if you do, you cannot change the exist tutorial, blog, and forums that refer /var/log/messages. Image the following scenario: Suppose a Fedora newbie (or linux newbie) encounters a problem, most of the search results state: Check /var/log/messages He/She will be very frustrated if he/she cannot find it. I am not saying that journalctl itself is not a good tool, in fact, I've played with it, so far it is working. However, I strongly recommend that we keep the default syslog until journalctl is well aware and adopted. -- Ding-Yi Chen Software Engineer Internationalization Group DID: +61 7 3514 8239 Email: dc...@redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Red Hat, Inc. Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Jul 15, 2013 5:51 PM, "Lennart Poettering" wrote: > > On Tue, 16.07.13 09:13, Dan Fruehauf (malko...@gmail.com) wrote: > > > > Well, there are certain things on Unix that are text files and many > > > things that are not. Binary log files have a long tradition on Unix, for > > > example in wtmp and utmp. We have binary files in /etc, and everywhere > > > else. > > > > > And the reason for that being? I have no idea either, it's probably too old > > to be dug. Howver yes, I'd like these to be text based as well. > > Oh, the reasons are pretty well-known for those cases. For example > wtmp/utmp is binary so that utmp works nicely as sparse file and the > entries may be accessed using the UID number as seek index (multipled by > the fixed entry size). So, it's about indexing, exactly as for journal > files. The Unix guys back then chose binary when it made sense for their > immediate technical requirements. And for us it's the exact same. I don't believe that was the reason, since when utmp was invented, Unix had 16-bit UIDs and did not have sparse files. On the other hand, I don't know the actual reason. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 9:51 AM, Lennart Poettering wrote: > On Tue, 16.07.13 09:13, Dan Fruehauf (malko...@gmail.com) wrote: > > > > Well, there are certain things on Unix that are text files and many > > > things that are not. Binary log files have a long tradition on Unix, > for > > > example in wtmp and utmp. We have binary files in /etc, and everywhere > > > else. > > > > > And the reason for that being? I have no idea either, it's probably too > old > > to be dug. Howver yes, I'd like these to be text based as well. > > Oh, the reasons are pretty well-known for those cases. For example > wtmp/utmp is binary so that utmp works nicely as sparse file and the > entries may be accessed using the UID number as seek index (multipled by > the fixed entry size). So, it's about indexing, exactly as for journal > files. The Unix guys back then chose binary when it made sense for their > immediate technical requirements. And for us it's the exact same. > What made sense back in the day is today yet another vague decision that was being dragged with us for decades - "because it made sense at the time". Going from text to binary is easy. Always easy to break things. Going back to text (if we want to) will be difficult. The above example is a really good one for why not to go binary, by all means. > > > > journalctl is certainly not a "complex tool" to understand. Command > > > lines usually get shorter by using it rather than the equivalent for > > > /var/log/messages. > > > > > People might also argue the event viewer in windows is not a "complex > > tool". See where it got them. Mind you event viewer is probably a bit > more > > mature than journalctl. > > Well, if I cannot convince you to even try it out, and you insist on > conflating the windows log viewer with journalctl (which is about as > smart as conflating microsoft word with vi), then I guess there's no > point in discussing this with you. > Perhaps there isn't. On the day I will boot a Linux system and have no /var/log/messages out of the box, it'll be time for a change. By all means any windows person I know would much rather have logs as plain text. Not the other way around. > > > > Lets try to keep things simple. This is why we use Fedora. This is > why I > > > > use Fedora. > > > > > > We are certainly making things simpler by introducing nice query tools > > > like journalctl and by reducing the number of packages we install by > > > default, and by removing redundancy. > > > > > Nice query tools? Lets go with a RDBMS to store the logs then? > > Nobody suggests that. > What's wrong with RDBMS? You only need to "echo 'select * from log' | SOME_SQL_PROGRAM | less", it's exactly the same and you also have all the querying capabilities of a RDBMS. > > > And for a short story about a system (I had nothing to do with) which > based > > their log files in a RDBMS and their configuration in XML format. Failed > > miserably. The end. > > We do neither. > You do neither, but you follow the very same path. > > Another question while we're at it - what happens if and when you decide > to > > change your binary format for storing files for whatever reason? Is that > > when we understand that we should have been left with just text based > files? > > We documented the format, and it is quite extensible. The sources are > open. Altogether this are the best guarantees that the stuff stays > stable and accessible. > Thanks, I'd still prefer it text. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F20 System Wide Change: ARM as primary Architecture (DJ D's Koji Time Script Mod)
Just in case anyone wanted a different view of the time differences for the F19 build tasks (PA vs ARM): http://scotland.proximity.on.ca/~jon/koji.times.html Source code is here based off of DJ Delorie's original work/script: http://scotland.proximity.on.ca/~jon/koji-times.txt Jon Chiappetta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
> Note that we do include journalctl on all our livecds. Also, most > distributions do include it in some way or another, and you do not need > to boot systemd to use to it access your journal files. Not true, RHEL 6 and its friends do not include journalctl. So if I want to cover both Fedora default and RHEL default, now I do have to look at two places instead of one. -- Ding-Yi Chen Software Engineer Internationalization Group DID: +61 7 3514 8239 Email: dc...@redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Red Hat, Inc. Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Hi On Mon, Jul 15, 2013 at 6:43 PM, Chris Adams wrote: > Once upon a time, Lennart Poettering said: > > On Mon, 15.07.13 16:42, Chris Adams wrote: > > > I assume you mean "arrow key to the right", but that doesn't work when > I > > > run "journalctl". I get "No next file" (and "No previous file" for > > > left-arrow). > > > > Yes, to the right. You are using less as a pager I presume? Scrolling to > > the right certainly works here. Please file a bug against less if it > > doesn't for you. > > No, the "bug" is journalctl, not less. If I run "journalctl | less", I > get wrapped lines. If I run "journalctl", I get truncated lines > (despite your repeated claims to the contrary). > Just file the bug report and it can be reassigned if necessary. No need to argue about it Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
On Mon, Jul 15, 2013 at 08:46:55PM -0500, Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > The total space taken by journal is limited by size and percantage of > > free space on the /var/log/journal filesystem [1], and age > > [2]. Individual journal files are limited by size and age [3,4]. > > Thanks, I see there's a journald.conf now. Another thing that would be > nice to add to the man page. Now that I know about it, I see the SEE > ALSO, but most things have a FILES section for that type stuff. Yes, people occasionally complain that systemd has too much documentation. That's why there's systemd.index(7) and systemd.directives(7) to make it easier to search for pages and settings. systemd-jouranld.service(8) now has a FILES section. Zbyszek -- they are not broken. they are refucktored -- alxchk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
Once upon a time, Zbigniew Jędrzejewski-Szmek said: > The total space taken by journal is limited by size and percantage of > free space on the /var/log/journal filesystem [1], and age > [2]. Individual journal files are limited by size and age [3,4]. Thanks, I see there's a journald.conf now. Another thing that would be nice to add to the man page. Now that I know about it, I see the SEE ALSO, but most things have a FILES section for that type stuff. -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 07:26:15PM -0500, Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > Sure, those are the defaults. If you had written that you don't like > > the systemd defaults, instead of talking about "bugs", this whole > > conversation would have been much productive. > > When I described the behavior, I was told I was wrong and that the lines > weren't chopped (which I then wondered why there was a "--full" option). > Neither the documentation or the emails mentioned that journalctl > overrides $LESS with the option to chop lines; I only found that out by > tracing the process. The UI is to a large degree a child of the git UI, I have to admit I find it self-explanatory. But I can see how one wouldn't think of pressing the right arrow, if one was convinced that jouranlctl has truncated the lines. An explanatory paragraph has been added to journalctl(1). > > > Another thing that I don't see in the man page is why some lines are > > > bold/in color. > > error -> red, notice -> bold, etc. > > Which Lennart said should be documented in the man page, which is now on > the to-do list. Also done. Both changes are online [1], and should be available in the next Fedora rawhide package. > > It's a feature you don't get traditionally because syslog drops the > > priority information from the on-disk format. > > I'd expect that if somebody thought that was an important default, the > log format would have been updated years ago when rsyslog became the > default. Not without (a) breaking scripts, (b) annoying people, because precious screen estate would be wasted on markers for the log level. Zbyszek -- they are not broken. they are refucktored -- alxchk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Visible Cloud
On Mon, Jul 15, 2013 at 12:21:11PM -0600, Kevin Fenzi wrote: > We've never provided updated live images down the road for security > issues. I understand cloud is a bit different, but we need to be clear > on the scope, IMHO. I guess it *is* worth noting that if you go to http://fedoraproject.org/ and click Download Now, you get that Live CD image, security flaws and all. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
On Mon, Jul 15, 2013 at 07:27:57PM -0500, Chris Adams wrote: > If it isn't too much of a thread-drift - this brings to mind another > question: how are the journal files rotated, archived, etc.? I don't > see anything in the man page. You can also use time-based rotation policies, but it's not very granular. If you're in an environment where data retention and lifecycle policies are important, you should install rsyslog or syslog-ng. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
On Mon, Jul 15, 2013 at 07:27:57PM -0500, Chris Adams wrote: > Once upon a time, Lennart Poettering said: > > Well, the duplicate log files will be accounted for every instance of a > > container/VM. The more containers you run, the more often you pay for > > it. This is different than just having one package installed too much in > > the image, which can be shared among instances. Written log files cannot. > > If it isn't too much of a thread-drift - this brings to mind another > question: how are the journal files rotated, archived, etc.? I don't > see anything in the man page. The total space taken by journal is limited by size and percantage of free space on the /var/log/journal filesystem [1], and age [2]. Individual journal files are limited by size and age [3,4]. [1] http://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse= [2] http://www.freedesktop.org/software/systemd/man/journald.conf.html#MaxRetentionSec= [3] http://www.freedesktop.org/software/systemd/man/journald.conf.html#MaxFileSec= [4] http://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse= (SystemMaxFileSize setting). Zbyszek -- they are not broken. they are refucktored -- alxchk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 8:26 PM, Chris Adams wrote: >> It's a feature you don't get traditionally because syslog drops the >> priority information from the on-disk format. > > I'd expect that if somebody thought that was an important default, the > log format would have been updated years ago when rsyslog became the > default. It's damn useful. There are tradeoffs, but you have take in the good aspects. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 02:46:27PM -0600, Eric Smith wrote: > I don't actually care whether there's a binary journal or not, but far > more of us have real usecases for /var/log/messages, so we shouldn't > give up that being available by default. If you use bash or ksh you could just replace /var/log/messages with <(journalctl) in your command line and stuff should just work (when reading). Other shells can probably do the same. It obviously depends on journalctl being able to run. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
Once upon a time, Lennart Poettering said: > Well, the duplicate log files will be accounted for every instance of a > container/VM. The more containers you run, the more often you pay for > it. This is different than just having one package installed too much in > the image, which can be shared among instances. Written log files cannot. If it isn't too much of a thread-drift - this brings to mind another question: how are the journal files rotated, archived, etc.? I don't see anything in the man page. -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, Zbigniew Jędrzejewski-Szmek said: > Sure, those are the defaults. If you had written that you don't like > the systemd defaults, instead of talking about "bugs", this whole > conversation would have been much productive. When I described the behavior, I was told I was wrong and that the lines weren't chopped (which I then wondered why there was a "--full" option). Neither the documentation or the emails mentioned that journalctl overrides $LESS with the option to chop lines; I only found that out by tracing the process. > > Another thing that I don't see in the man page is why some lines are > > bold/in color. > error -> red, notice -> bold, etc. Which Lennart said should be documented in the man page, which is now on the to-do list. > It's a feature you don't get traditionally because syslog drops the > priority information from the on-disk format. I'd expect that if somebody thought that was an important default, the log format would have been updated years ago when rsyslog became the default. -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 11:28:48PM +0200, Lennart Poettering wrote: > But this is a really different discussion anyway. I know some people > hate auto-paging, but I am pretty sure more people learned to love it > since it was introduced by git. I love auto-paging for sure. The difference between git's autopaging and journalctl is that with git log the most recent commits come first while log files have the most likely interesting stuff at the end. There's "journalctl -e" and "journalctl -r" (as well as the more specific query options, of course) so it should just take some time to get used to it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
On Mon, 15.07.13 17:21, Stephen John Smoogen (smo...@gmail.com) wrote: > On 15 July 2013 16:39, Matthew Miller wrote: > > > I'm putting this in a separate thread so it doesn't get buried in the > > enthusiasm over the other one. :) > > > > Here's our dilemma (Or trilemma?) in the Fedora Cloud SIG. > > > > 1) Double-logging is a significant waste of scarce resources > > > > > Well I can see IO resources as being scarse but how scarse are we really > talking? [There comes a point where cutting down the size of an image isn't > going to help a bit because it takes up the same number of sectors on a > disk whether its X Mb or Y Mb. Well, the duplicate log files will be accounted for every instance of a container/VM. The more containers you run, the more often you pay for it. This is different than just having one package installed too much in the image, which can be shared among instances. Written log files cannot. > > 3) If we leave out rsyslog, we lose text /var/log/messages ... > >... which is less of a big deal from the server-room emergency-analysis > >angle that might apply in the general case ... > >... but it's a pretty big change from the rest of Fedora, and we'd > >prefer not to do that just for the cloud image. > > > > > So if I am going to spin up a lot of boxes.. I am going to want those logs > not on one box but transmitted to a central location. Does journald have > remote logging capabilities (will it?) Well, it currently doesn't have full featured solution. However, it has some bits and pieces around to make it work nicely for some usecases: if you share /var/log/journal between multiple hosts or containers, then you can use "journalctl -m" to view them all at the same time and nicely interleaved. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 06:39:59PM -0500, Chris Adams wrote:
> Actually, journalctl DOES do something other than popen("less"); it
> overrides the user's $LESS and sets it to "FRSXMK" (the S option tells
> less to chop lines). So while technically journalctl is not chopping
> lines, it is forcing less to do so. A user's $LESS should not be
> overridden, especially to chop log lines.
Although the less man page says that lines are "chopped", they actually
_should_ be available for scrolling to the right and back to the left. That
is, the lines are not truncated.
I had an RFE about this in bugzilla somewhere. It's hard because some
options which make sense for a general pager don't for journal paging, so
it's better to set a sane set of options. You can set the systemd-specific
pager variable if you think it should be different. (You can set that to
`cat` and then presto, no paging.)
> Another thing that I don't see in the man page is why some lines are
> bold/in color.
That's a documentation bug. It's not in the man page but explained here
http://0pointer.de/blog/projects/journalctl.html
* Lines of error priority (and higher) will be highlighted red.
* Lines of notice/warning priority will be highlighted bold.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 18:39, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > On Mon, Jul 15, 2013 at 05:43:43PM -0500, Chris Adams wrote:
> > > No, the "bug" is journalctl, not less. If I run "journalctl | less", I
> > > get wrapped lines. If I run "journalctl", I get truncated lines
> > > (despite your repeated claims to the contrary).
> > [At least in default configuration] you can switch between "truncated"
> > and "non-truncated" output by pressing -S, or view the "truncated"
> > part by pressing right arrow. If you're seeing something different,
> > then please file a bug (against less, because journalctl doesn't really
> > do anything other than popen("less") here). For reference, try pressing
> > 'h' in less, I see:
>
> Actually, journalctl DOES do something other than popen("less"); it
> overrides the user's $LESS and sets it to "FRSXMK" (the S option tells
> less to chop lines). So while technically journalctl is not chopping
> lines, it is forcing less to do so. A user's $LESS should not be
> overridden, especially to chop log lines.
Well, they arent't "chopped". You can scroll to the right and you can
see them.
We didn't override LESS initially, but we got bugs about that, and after
a while of forth and back we followed again what git does here and
override it. You find the discussions in bugzilla.
> Another thing that I don't see in the man page is why some lines are
> bold/in color.
Log priorities. This is indeed missing in the man pages. Added to the
TODO list now, to fix.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 06:39:59PM -0500, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > On Mon, Jul 15, 2013 at 05:43:43PM -0500, Chris Adams wrote:
> > > No, the "bug" is journalctl, not less. If I run "journalctl | less", I
> > > get wrapped lines. If I run "journalctl", I get truncated lines
> > > (despite your repeated claims to the contrary).
> > [At least in default configuration] you can switch between "truncated"
> > and "non-truncated" output by pressing -S, or view the "truncated"
> > part by pressing right arrow. If you're seeing something different,
> > then please file a bug (against less, because journalctl doesn't really
> > do anything other than popen("less") here). For reference, try pressing
> > 'h' in less, I see:
>
> Actually, journalctl DOES do something other than popen("less"); it
> overrides the user's $LESS and sets it to "FRSXMK" (the S option tells
> less to chop lines). So while technically journalctl is not chopping
> lines, it is forcing less to do so. A user's $LESS should not be
> overridden, especially to chop log lines.
Sure, those are the defaults. If you had written that you don't like
the systemd defaults, instead of talking about "bugs", this whole
conversation would have been much productive.
The default was picked as is, after some back-and-forth, because this
way it much easier to browse through a long listing. You can always
change *your* default by sticking
export SYSTEMD_PAGER='less -FRX -+S'
in your .bashrc or wherever.
> Another thing that I don't see in the man page is why some lines are
> bold/in color.
error -> red, notice -> bold, etc.
It's a feature you don't get traditionally because syslog drops the
priority information from the on-disk format.
Zbyszek
--
they are not broken. they are refucktored
-- alxchk
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 09:13, Dan Fruehauf (malko...@gmail.com) wrote: > > Well, there are certain things on Unix that are text files and many > > things that are not. Binary log files have a long tradition on Unix, for > > example in wtmp and utmp. We have binary files in /etc, and everywhere > > else. > > > And the reason for that being? I have no idea either, it's probably too old > to be dug. Howver yes, I'd like these to be text based as well. Oh, the reasons are pretty well-known for those cases. For example wtmp/utmp is binary so that utmp works nicely as sparse file and the entries may be accessed using the UID number as seek index (multipled by the fixed entry size). So, it's about indexing, exactly as for journal files. The Unix guys back then chose binary when it made sense for their immediate technical requirements. And for us it's the exact same. > > journalctl is certainly not a "complex tool" to understand. Command > > lines usually get shorter by using it rather than the equivalent for > > /var/log/messages. > > > People might also argue the event viewer in windows is not a "complex > tool". See where it got them. Mind you event viewer is probably a bit more > mature than journalctl. Well, if I cannot convince you to even try it out, and you insist on conflating the windows log viewer with journalctl (which is about as smart as conflating microsoft word with vi), then I guess there's no point in discussing this with you. > > > Lets try to keep things simple. This is why we use Fedora. This is why I > > > use Fedora. > > > > We are certainly making things simpler by introducing nice query tools > > like journalctl and by reducing the number of packages we install by > > default, and by removing redundancy. > > > Nice query tools? Lets go with a RDBMS to store the logs then? Nobody suggests that. > And for a short story about a system (I had nothing to do with) which based > their log files in a RDBMS and their configuration in XML format. Failed > miserably. The end. We do neither. > Another question while we're at it - what happens if and when you decide to > change your binary format for storing files for whatever reason? Is that > when we understand that we should have been left with just text based files? We documented the format, and it is quite extensible. The sources are open. Altogether this are the best guarantees that the stuff stays stable and accessible. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
On Mon, Jul 15, 2013 at 11:35:48PM +, "Jóhann B. Guðmundsson" wrote: > On 07/15/2013 11:34 PM, Matthew Miller wrote: > >journald doesn't have remote logging capabilities and it's my understanding > >that it's a non-goal. Personally, I'd be interested in seeing a lightweight > >forwarder which integrates with, say, Logstash. > Well let's not forget and easily dismiss the journal gateway... I haven't forgotten it. It would be interesting were that to grow into something useful. And like rsyslog, I'd prefer it not to be installed by default. *cough* *cough* https://bugzilla.redhat.com/show_bug.cgi?id=908081 -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 07:25:28PM -0400, Matthew Miller wrote: > On Tue, Jul 16, 2013 at 09:13:24AM +1000, Dan Fruehauf wrote: > > Another question while we're at it - what happens if and when you decide to > > change your binary format for storing files for whatever reason? Is that > > when we understand that we should have been left with just text based files? > > A stable, documented journal format is a prerequisite for this feature. > > http://www.freedesktop.org/wiki/Software/systemd/journal-files/ > > That page outlines the plan for compatibility and for future extensions, and > it seems reasonable to me. Just to add to that: the format has already been sucessfully extended twice: first to add XZ compression of fields, and second time to add forward sealing. Zbyszek -- they are not broken. they are refucktored -- alxchk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> On Mon, Jul 15, 2013 at 05:43:43PM -0500, Chris Adams wrote:
> > No, the "bug" is journalctl, not less. If I run "journalctl | less", I
> > get wrapped lines. If I run "journalctl", I get truncated lines
> > (despite your repeated claims to the contrary).
> [At least in default configuration] you can switch between "truncated"
> and "non-truncated" output by pressing -S, or view the "truncated"
> part by pressing right arrow. If you're seeing something different,
> then please file a bug (against less, because journalctl doesn't really
> do anything other than popen("less") here). For reference, try pressing
> 'h' in less, I see:
Actually, journalctl DOES do something other than popen("less"); it
overrides the user's $LESS and sets it to "FRSXMK" (the S option tells
less to chop lines). So while technically journalctl is not chopping
lines, it is forcing less to do so. A user's $LESS should not be
overridden, especially to chop log lines.
Another thing that I don't see in the man page is why some lines are
bold/in color.
--
Chris Adams
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
On 07/15/2013 11:34 PM, Matthew Miller wrote: journald doesn't have remote logging capabilities and it's my understanding that it's a non-goal. Personally, I'd be interested in seeing a lightweight forwarder which integrates with, say, Logstash. Well let's not forget and easily dismiss the journal gateway... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
On Mon, Jul 15, 2013 at 05:21:02PM -0600, Stephen John Smoogen wrote: > > 1) Double-logging is a significant waste of scarce resources > Well I can see IO resources as being scarse but how scarse are we really > talking? [There comes a point where cutting down the size of an image isn't > going to help a bit because it takes up the same number of sectors on a > disk whether its X Mb or Y Mb. I think "enough scarce that we should attempt to minimize the default system use of them so that people can make their own decisions". I'm also not particularly keen on just the plain space for storing the logs themselves. > So if I am going to spin up a lot of boxes.. I am going to want those logs > not on one box but transmitted to a central location. Does journald have > remote logging capabilities (will it?) Right, exactly. In that case, you'd install rsyslog, but not configure it to write a thing locally -- just have it forward everything you want forwarded. journald doesn't have remote logging capabilities and it's my understanding that it's a non-goal. Personally, I'd be interested in seeing a lightweight forwarder which integrates with, say, Logstash. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 07/15/2013 11:15 PM, Matthew Miller wrote: On Mon, Jul 15, 2013 at 11:02:09PM +, "Jóhann B. Guðmundsson" wrote: I would assume they take into account hard valid technical arguments not change in workflow ( which any change might bring ) or people pluses or minuses but maybe that's just my wishful thinking. "This has a change in workflow" _is_ hard, valid technical argument. Any change needs to overcome that in one of two ways: 1) minimize the pain of transition with compatibility paths, documentation, and serious thought about the user experience for current users; and 2) bring significant new value that weighs against it. The best changes work on both sides of the equation, of course. Yes we followed that rule of thumb when we introduced those changes with anaconda/systemd/gnome3 etc ;) Anyway awhile back I did not file that ticket with FPC rsyslog proposal just because, with my QA hat on I can say daemon/service solution that depend on text files something like fail2ban etc. is what we need to be watching out for and that's where the breakage will be and afaik nothing has been done to a) figure out which components those are ( and it will be hard to detect them all due to components not properly depend on rsyslog syslog-ng etc or even logwatch for that matter ) b) fix it ( which my FPC proposal was aiming for, with me actually doing the fixing part ). c) not seen maintainers that do maintain components that rely on files in /var/log chime in But fesco get's to do all that research to properly determine the actual cause and effects and the scope of removing rsyslog... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 05:43:43PM -0500, Chris Adams wrote:
> Once upon a time, Lennart Poettering said:
> > On Mon, 15.07.13 16:42, Chris Adams (li...@cmadams.net) wrote:
> > > I assume you mean "arrow key to the right", but that doesn't work when I
> > > run "journalctl". I get "No next file" (and "No previous file" for
> > > left-arrow).
> >
> > Yes, to the right. You are using less as a pager I presume? Scrolling to
> > the right certainly works here. Please file a bug against less if it
> > doesn't for you.
>
> No, the "bug" is journalctl, not less. If I run "journalctl | less", I
> get wrapped lines. If I run "journalctl", I get truncated lines
> (despite your repeated claims to the contrary).
[At least in default configuration] you can switch between "truncated"
and "non-truncated" output by pressing -S, or view the "truncated"
part by pressing right arrow. If you're seeing something different,
then please file a bug (against less, because journalctl doesn't really
do anything other than popen("less") here). For reference, try pressing
'h' in less, I see:
ESC-) RightArrow * Left one half screen width (or N positions).
ESC-( LeftArrow * Right one half screen width (or N positions).
If you have something different, then it probably is a config difference.
Zbyszek
--
they are not broken. they are refucktored
-- alxchk
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 7:06 AM, Lennart Poettering wrote: > On Mon, 15.07.13 14:53, Eric Smith (brouh...@fedoraproject.org) wrote: > > > > The need for > > > /var/log/messages filters down to wanting to use less or shell > > > built-ins to read the data, which is a valid usecase, but not > > > worth the overhead in 99% of cases. > > > > But it's what people actually use in 99.9% of cases. 99.9% of the > > time I don't need the extra information in the binary journal. Making > > /var/log/messages unavailable by default has a huge down side. > > > > If we go to having only binary logs by default, maybe we should also > > go to having only binary configuration files by default. It's > > basically the same arguments: there's more information available; it's > > easier for software to parse; it can be made more reliable; special > > tools are OK and people don't really need to open it in a text editor. > > We've seen how well that works on Windows. Blech. > > Nobody is proposing this. Slippery slope arguments seldom are > particularly convincing... > Slippery slope arguments is what will make Fedora stop being Linux and become a bunch of utilities to parse some binary format files on top of a Linux kernel. > > And it's easy to turn this around: by following your logic we really > should get rid of ELF binaries and instead write everything in some > scripting language instead, since ELF binaries are, well, binary... > That's pretty silly. But as much as I'm opposed to journalctl, I would have been opposed to changing anything else which is Bash based to something that's ELF, unless there is a good argument for that (performance... or?). Compiled stuff adds many times unneeded complexity. > > It's a matter of finding the right balance: i.e. what can be text files, > and where we have to win more by making it binary. I am pretty sure this > is a case where we win more by sticking to binary files. It's totally > fine if you disagree on this, but I'd still like to ask you to think > about whether your specific usecase and specific requirements are strong > enough to (continue to) be the default for Fedora, instead of just being > your local configuration of Fedora. > The right balance is definitely not having log files as a binary format. We don't need use cases for log files. Log files should be plain text, plain simple, portable, accessible. journalctl is doing the exact opposite and not providing much benefit. Honestly Lennart, this is something that will make people start hating Fedora. Especially people who deal with crashes, recovery and support. > > I mean, you should never forget that on your own machines everything > will stay as is: you will install syslog, and things will be exactly as > before. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 09:13:24AM +1000, Dan Fruehauf wrote: > Another question while we're at it - what happens if and when you decide to > change your binary format for storing files for whatever reason? Is that > when we understand that we should have been left with just text based files? A stable, documented journal format is a prerequisite for this feature. http://www.freedesktop.org/wiki/Software/systemd/journal-files/ That page outlines the plan for compatibility and for future extensions, and it seems reasonable to me. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cloud images and journald/rsyslog
On 15 July 2013 16:39, Matthew Miller wrote: > I'm putting this in a separate thread so it doesn't get buried in the > enthusiasm over the other one. :) > > Here's our dilemma (Or trilemma?) in the Fedora Cloud SIG. > > 1) Double-logging is a significant waste of scarce resources > > Well I can see IO resources as being scarse but how scarse are we really talking? [There comes a point where cutting down the size of an image isn't going to help a bit because it takes up the same number of sectors on a disk whether its X Mb or Y Mb. > 2) If we disable persistent journald (the f19 approach), we lose the >nice features that journalctl offers. And, they really are nice. > > 3) If we leave out rsyslog, we lose text /var/log/messages ... >... which is less of a big deal from the server-room emergency-analysis >angle that might apply in the general case ... >... but it's a pretty big change from the rest of Fedora, and we'd >prefer not to do that just for the cloud image. > > So if I am going to spin up a lot of boxes.. I am going to want those logs not on one box but transmitted to a central location. Does journald have remote logging capabilities (will it?) As it is, I don't have a problem with it not being in minimal but being in the @standard setting. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 11:02:09PM +, "Jóhann B. Guðmundsson" wrote: > I would assume they take into account hard valid technical arguments > not change in workflow ( which any change might bring ) or people > pluses or minuses but maybe that's just my wishful thinking. "This has a change in workflow" _is_ hard, valid technical argument. Any change needs to overcome that in one of two ways: 1) minimize the pain of transition with compatibility paths, documentation, and serious thought about the user experience for current users; and 2) bring significant new value that weighs against it. The best changes work on both sides of the equation, of course. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 1:55 AM, Lennart Poettering wrote: > On Tue, 16.07.13 00:55, Dan Fruehauf (malko...@gmail.com) wrote: > > > +1 - same here. You're far from being alone. > The +1 BTW was on Miroslav's comment. Obviously I'm against that change. > > > > I'm still trying to get used to the new systemd in Fedora and still > trying > > to think why I need it. Altogether for my day to day use I find it as > added > > complexity with no real benefit cerca f15. > > > > Unix/Linux for me is the simplicity of text files. If I lose the > simplicity > > of text files I just wonder what is left for me? A bunch of vague files > in > > a binary format I need complex tools to decipher? Might as well just > > install win7 and utilize my gfx card. > > Well, there are certain things on Unix that are text files and many > things that are not. Binary log files have a long tradition on Unix, for > example in wtmp and utmp. We have binary files in /etc, and everywhere > else. > And the reason for that being? I have no idea either, it's probably too old to be dug. Howver yes, I'd like these to be text based as well. > > journalctl is certainly not a "complex tool" to understand. Command > lines usually get shorter by using it rather than the equivalent for > /var/log/messages. > People might also argue the event viewer in windows is not a "complex tool". See where it got them. Mind you event viewer is probably a bit more mature than journalctl. > > "cat /var/log/messages" becomes just "journalctl" > > "tail -f /var/log/messages" becomes "journalctl -f" > > "tail -n 100 /var/log/messages" becomes "journalctl -n 100" > > "grep foo /var/log/messages" becomes journalctl | grep foo" > All of these examples add a magnitude of complexity in terms of code. I'm unconvinced. > > And the outputs of these files are the exact same text streams you are > used to. However, enhanced with a lot of niceties that make them more > user friendly. For example, you get colors based on the log level, or > there's a line drawn between reboots. You get the time zone corrected, > and you get unconditional PID data, you can filter very very easy, the > data is unfakable and so on. > > Just think about this: > > "journalctl -b" shows you output of the current boot only > > "journalctl --since=today" shows you the output of today only > > "journalctl -p notice" shows you only notice and error messages > (i.e. all the important stuff) > > "journaclctl -u crond" shows you only the messages from cron. > > ... and so on. > > Now try to think how hard it is to express queries the same way on > classic syslog. And how slow they become on larger database because they > aren't indexed. > > journalctl makes a lot of things easier, much easier. If you say it is > complex or difficult to use I am pretty sure you never had a closer look > at it. > > (Also, I am not sure what you mean by "vague". Please note that the file > format is fully documented: > http://www.freedesktop.org/wiki/Software/systemd/journal-files/ also, we > commited to an API for them and more) > I'm pretty sure somewhere also the windows binary format is documented. > > > Lets try to keep things simple. This is why we use Fedora. This is why I > > use Fedora. > > We are certainly making things simpler by introducing nice query tools > like journalctl and by reducing the number of packages we install by > default, and by removing redundancy. > Nice query tools? Lets go with a RDBMS to store the logs then? And for a short story about a system (I had nothing to do with) which based their log files in a RDBMS and their configuration in XML format. Failed miserably. The end. Another question while we're at it - what happens if and when you decide to change your binary format for storing files for whatever reason? Is that when we understand that we should have been left with just text based files? > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 04:21:57PM -0600, Eric Smith wrote: > > And honestly I dont understand why people are ack/nack-ing this since this > > is FESCO decision > Some of us would like to think that FESCO members might be influenced > by arguments made on the development list. Maybe that's just wishful > thinking. If you mean arguments in the constructive sense, then, yes. That's the whole point of this process where the changes are posted for discussion. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
That's the point. You don't get to be a primary architecture until you've demonstrated that doing so won't slow down the other architectures >>> Is that "you don't get to be a primary architecture unless you have >>> demonstrated that nobody outside of the ARM SIG needs to do any work >>> on the architecture" == "you don't get to be a primary architecture >>> unless it doesn't matter whether you are a primary architecture"? >> >> Promotion is supposed to benefit Fedora, not the architecture being >> promoted. > > Is this some rule that I don't know about? Surely promotion is supposed > to benefit Fedora's users. Couldn't agree wholeheartedly! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 07/15/2013 10:21 PM, Eric Smith wrote: On Mon, Jul 15, 2013 at 3:53 PM, "Jóhann B. Guðmundsson" wrote: And honestly I dont understand why people are ack/nack-ing this since this is FESCO decision Some of us would like to think that FESCO members might be influenced by arguments made on the development list. Maybe that's just wishful thinking. I would assume they take into account hard valid technical arguments not change in workflow ( which any change might bring ) or people pluses or minuses but maybe that's just my wishful thinking. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: feature process [was Re: F20 System Wide Change: No Default Syslog]
On 07/15/2013 10:16 PM, Matthew Miller wrote: On Mon, Jul 15, 2013 at 09:53:56PM +, "Jóhann B. Guðmundsson" wrote: And honestly I dont understand why people are ack/nack-ing this since this is FESCO decision and actually with my QA hat on we could have been better prepared for this and worked to our advantage ( instead of be dealing with potential breakage afterwards) and would have done so when I submitted [1] but apparently such work flow are forbidden by FESCO/FPC in the project. I'm not sure what you're talking about with all of that. The entire discussion of the previous proposal is at http://meetbot.fedoraproject.org/fedora-meeting/2012-03-19/fesco.2012-03-19-18.00.log.html and I'm not seeing anything about a forbidden workflow. I see - journald doesn't cover all rsyslog functionality; this time around the proposal talks about that as on purpose - Something about "project lumberjack", but that's based around a government project which is now dead: http://cee.mitre.org/ And https://lists.fedorahosted.org/pipermail/lumberjack-developers/ is likewise stagnant. - impact of change not explained thoroughly enough; hopefully that too is better now - "not thrilled" about binary log - "don't think it's worth the effort at this point. maybe in the future..." - and "yeah, -1 for now. it just doesn't appear to be really ready yet." This was just about disabling it even just up to beta so we could catch fallouts early on then fix then switch as opposed to switch try deal with breakage just before release and FESCO did not approve that which is that "forbidden workflow" and obviously that only applies to the FESCO at that time and the same members of FESCO then and now which I would be surprised if they have changed their opinions which I myself will be very interested to see why. I also had previously started a discussion about reasonable blockers for making journald the default, and there was good progress on that (with many of the things which came out as crucial crossed off the list). So the situation is different from how it was, plus of course the code has had some time time mature, all of which is why I agreed to sign on. (In addition to it being useful for the cloud image use case.) Here [1] FESCO points to FPC <---> FPC points to FESCO Ironically this should be fixed regardless if the journal is default/only installed or not and actually from my pov this just makes it harder for FESCO to make that decision but hey FPC greatest thing since sliced bread The fact is the our implementation of rsyslog or syslog-ng logwatch etc. in the distribution is not good, even the proper dependency between those components is missing. JBG 1.https://fedorahosted.org/fpc/ticket/142 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why can't ExecStopPre= be used to abort stopping a (broken) service?
On 07/15/2013 10:15 PM, Paul Wouters wrote: The correct way here is to stay true to what is tried and tested in the legacy sysv init scripts and add the config parser to the ExecStartPre= line in the unit file. I have that now, but it still causing the service to terminate after a "restart", which I think is less desirable than running with the old config. But again, with the option there, people can choose what they prefer. Indeed but I was thinking more distro wide as in enabling this by default ( which makes sense if we add this ) for those service/daemon that support config parsing followed by Restart=on-failure which would deliver 99.9% uptime of the service/daemon. ( the only down time being when the admin shutdowns the service or it being restarted during updates ) but here is just that problem if notifying the admin of the parsing error.. You might actually be able to hack your self around this via double ExecStop= lines one with the conf parser followed by the actual daemon/service ExecStop line. I guess if we are going to support ExecRestartPre= we need to also add ExecReloadPre= and arguably if we do add this we should update the units for the reason I mention here above. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
cloud images and journald/rsyslog
I'm putting this in a separate thread so it doesn't get buried in the enthusiasm over the other one. :) Here's our dilemma (Or trilemma?) in the Fedora Cloud SIG. 1) Double-logging is a significant waste of scarce resources 2) If we disable persistent journald (the f19 approach), we lose the nice features that journalctl offers. And, they really are nice. 3) If we leave out rsyslog, we lose text /var/log/messages ... ... which is less of a big deal from the server-room emergency-analysis angle that might apply in the general case ... ... but it's a pretty big change from the rest of Fedora, and we'd prefer not to do that just for the cloud image. So, it'd be nice to at least have rsyslogd moved from @core to @standard (from minimal to default). I'm also pretty well sold on the idea that journald is better on the desktop. But that's not my thing. On the server, I don't think I've _ever_ run a serious system where I didn't have a custom syslog configuration (be it sysklogd, rsyslog, or syslog-ng). I absolutely don't think that will go away. (And on those systems, generally I don't look in /var/log/messages anymore anyway.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, Lennart Poettering said: > On Mon, 15.07.13 16:42, Chris Adams (li...@cmadams.net) wrote: > > I assume you mean "arrow key to the right", but that doesn't work when I > > run "journalctl". I get "No next file" (and "No previous file" for > > left-arrow). > > Yes, to the right. You are using less as a pager I presume? Scrolling to > the right certainly works here. Please file a bug against less if it > doesn't for you. No, the "bug" is journalctl, not less. If I run "journalctl | less", I get wrapped lines. If I run "journalctl", I get truncated lines (despite your repeated claims to the contrary). -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15 Jul 2013 16:21:57 -0600 Eric Smith wrote: > On Mon, Jul 15, 2013 at 3:53 PM, "Jóhann B. Guðmundsson" > wrote: > > And honestly I dont understand why people are ack/nack-ing this > > since this is FESCO decision > > Some of us would like to think that FESCO members might be influenced > by arguments made on the development list. Maybe that's just wishful > thinking. I can't speak for anyone else in FESCo, but I do read everything posted here and try and keep an open mind. Of course arguments with facts and logic are much more likely to sway my opinion than ones with "I don't like this", "+1", or folks who repeat themselves without adding anything new to the discussion. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 16.07.2013 00:21, Eric Smith wrote: > On Mon, Jul 15, 2013 at 3:53 PM, "Jóhann B. Guðmundsson" > wrote: >> And honestly I dont understand why people are ack/nack-ing this since this >> is FESCO decision > Some of us would like to think that FESCO members might be influenced > by arguments made on the development list. Maybe that's just wishful > thinking. > > Eric I don't know how it goes with FESCO but once, there was a community voice that was heard by developers about Anaconda not hiding password characters during installation. Don't lose your faith. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 3:37 PM, Matthew Miller wrote: > On Fri, Jul 12, 2013 at 02:17:28PM +, "Jóhann B. Guðmundsson" wrote: >> 1. https://bugzilla.redhat.com/show_bug.cgi?id=949328 >> 2. https://bugzilla.redhat.com/show_bug.cgi?id=869540 > > Often, people maintain a package because it's required for a certain use > case they have not necessarily for particular love for that package. That's > not the idea situation, but it's better than not having the package at all, > and crucially, it means the actual use case that someone cares about is > covered. Really? There's packages that have been built once and never updated that have CVEs and bugs that the "maintainer" never deals with. The vast majority of ARM build "issues" I've dealt with aren't ARM issues at all. They're maintainers not fixing problems or updating their own packages and when ever I fix a problem with a package with ARM problems I check the bugs and build problems against mainline and in the vast majority of cases the problems on ARM are actually problems on x86. > I'm sure Peter would be happy to have a co-maintainer for the syslinux > package. I'd volunteer, but I'm actually _also_ only interested in a small > subset of functionality and am not able to address the bigger picture > either. But if someone would show up and really want to do it justice, > *awesome*. So in a lot of cases ARM is only interested in a small subset of cases but I still fix other issues. Other maintainers pick up packages because they're only interested in a subset. I'll use llvm as an example here because ajax has openly said he's only interested in a subset and he openly quoted it earlier in the thread. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 3:53 PM, "Jóhann B. Guðmundsson" wrote: > And honestly I dont understand why people are ack/nack-ing this since this > is FESCO decision Some of us would like to think that FESCO members might be influenced by arguments made on the development list. Maybe that's just wishful thinking. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 1:08 PM, David Tardon wrote: > On Thu, Jul 11, 2013 at 06:06:04PM +, "Jóhann B. Guðmundsson" wrote: >> On 07/11/2013 02:04 PM, Miloslav Trmač wrote: >> >On Wed, Jul 10, 2013 at 3:56 PM, "Jóhann B. Guðmundsson" >> > wrote: >> >>Each sub-community ( be it spins be it various arch ) should need to >> >>provide >> >>the necessary QA/Releng resources from their sub-community ( if no such >> >>thing the relevant party needs to build one ) >> >That would be interesting and quite possibly very beneficial, however >> >the transition from the current system when most people "don't need to >> >care" would be a complex, longer-term cultural shift that shouldn't be >> >(and doesn't really need to be) a blocker for the ARM feature. >> >> I dont argue that this should be a blocker for architectures quite >> the opposite as far as I see it the only requirement for an >> architecture to be come a "primary" ( thou arguably those are >> outdated concepts as well ) is that all package currently build ( >> with the execption if they simply cannot work on a spesific >> architecture ) and be available for the community to use as lego >> bricks to shape and present to the world as they image in for that >> relevant hw. > > It is only a few weeks you argued that we should drop all packages that > are not "properly maintained". Actually from an ARM perspective that would be a bonus as I spend a lot more of my time fixing packages that are broken on mainline so that I can see if they build on ARM which in 80% ish of the cases just fixes the ARM build issues, in another 10% of cases updating the package to the latest upstream release fixes the ARM build issues, there's a percentage point or two where there's problems in the packaging or using non distro build options like CFLAGS. The vast majority of the packaging issues I deal with on ARM are not actually ARM specific and often fix the other secondary arches as well! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
feature process [was Re: F20 System Wide Change: No Default Syslog]
On Mon, Jul 15, 2013 at 09:53:56PM +, "Jóhann B. Guðmundsson" wrote: > And honestly I dont understand why people are ack/nack-ing this > since this is FESCO decision and actually with my QA hat on we could > have been better prepared for this and worked to our advantage ( > instead of be dealing with potential breakage afterwards) and would > have done so when I submitted [1] but apparently such work flow are > forbidden by FESCO/FPC in the project. I'm not sure what you're talking about with all of that. The entire discussion of the previous proposal is at http://meetbot.fedoraproject.org/fedora-meeting/2012-03-19/fesco.2012-03-19-18.00.log.html and I'm not seeing anything about a forbidden workflow. I see - journald doesn't cover all rsyslog functionality; this time around the proposal talks about that as on purpose - Something about "project lumberjack", but that's based around a government project which is now dead: http://cee.mitre.org/ And https://lists.fedorahosted.org/pipermail/lumberjack-developers/ is likewise stagnant. - impact of change not explained thoroughly enough; hopefully that too is better now - "not thrilled" about binary log - "don't think it's worth the effort at this point. maybe in the future..." - and "yeah, -1 for now. it just doesn't appear to be really ready yet." I also had previously started a discussion about reasonable blockers for making journald the default, and there was good progress on that (with many of the things which came out as crucial crossed off the list). So the situation is different from how it was, plus of course the code has had some time time mature, all of which is why I agreed to sign on. (In addition to it being useful for the cloud image use case.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why can't ExecStopPre= be used to abort stopping a (broken) service?
On Mon, 15 Jul 2013, "Jóhann B. Guðmundsson" wrote: If I grok correctly what you are asking for, you are actually looing for an ExecRestartPre=, not an ExecStopPre=. You want somthing that is run before we stop a service when we intend to restart it. But when we shutdown the system and stop the service for that, or if the user wants to stop it manually, we shouldn't run it, correct? If that's what you want, then yes, it is on the TODO list to add something like this Yes that is what I'm asking for. Great to know it is on the TODO. Adding that does not make much sense. For the first in 99% use cases are covered via ExecStartPre= That does not cover the config file changing in a way that introduced an error preventing the service from starting if it ever got stopped. Secondly the fact is that the admin would never notice the configuration error because he Admin makes incorrect change to config file --> then restart the service --> the service would not fail Yes the systemctl command would fail with an exit code. A syslog message would be logged. The fact that the restart did not get to even call the stop part does not mean the command returns without failure. The fact is the only way admin will notices and react to this, is if the service will hard fail upon restart and systemd should not be working around admin mistakes in configuration file. That's great for the 1 admin or 1 machine solution, but does not work when you script an update via puppet or ansible and it fails somehow on some machines (eg let's see those machines have an older version of the daemon and now the new config option kills it) The correct way here is to stay true to what is tried and tested in the legacy sysv init scripts and add the config parser to the ExecStartPre= line in the unit file. I have that now, but it still causing the service to terminate after a "restart", which I think is less desirable than running with the old config. But again, with the option there, people can choose what they prefer. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 9:08 AM, Adam Williamson wrote: > On Thu, 2013-07-11 at 22:07 -0400, Frank Ch. Eigler wrote: >> Adam Williamson writes: >> >> > [...] "Primary Architectures : These are architectures with the >> > majority of the users, the most common architectures. [...] >> >> By that standard, PA treatment of ARM seems way premature. > > XO 1.75, /endofthread ;) Not sure what you mean by that? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 00:05, Mateusz Marzantowicz (mmarzantow...@osdf.com.pl) wrote: > On 15.07.2013 23:49, Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jul 15, 2013 at 11:38:14PM +0200, Mateusz Marzantowicz wrote: > >> On 15.07.2013 23:06, Lennart Poettering wrote: > >>> It's a matter of finding the right balance: i.e. what can be text > >>> files, and where we have to win more by making it binary. I am pretty > >>> sure this is a case where we win more by sticking to binary files. > >>> It's totally fine if you disagree on this, but I'd still like to ask > >>> you to think about whether your specific usecase and specific > >>> requirements are strong enough to (continue to) be the default for > >>> Fedora, instead of just being your local configuration of Fedora. I > >>> mean, you should never forget that on your own machines everything > >>> will stay as is: you will install syslog, and things will be exactly > >>> as before. Lennart > >> So maybe we (Fedora) should go with XML instead of binary or some > >> dedicated RDMBS for storing system logs? I'm not against binary log > >> format but try to understand why it's superior to text and also why > >> something more sophisticated isn't used if we really need this > >> additional meta data that could not be included in plain text? > > With a binary format you can have an index of field -> offset, > > hash->offset, etc., and then you can jump to this offset and read data > > there. With text files, and with XML files, this is not possible, at > > least not in any sane way. Efficiency would be much worse too. > > > > OK, XML is also text so my alternative is a bit illusory but it > could be represented as DOM nodes and could be indexed easier and more > efficiently. Please, see how good is XML implementation in PostgreSQL. > You can say, it's too much and too complicated for stupid system logs to > go with fully blown RDBMS solution, but hey, really? Yes. Really. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 15.07.2013 23:49, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jul 15, 2013 at 11:38:14PM +0200, Mateusz Marzantowicz wrote: >> On 15.07.2013 23:06, Lennart Poettering wrote: >>> It's a matter of finding the right balance: i.e. what can be text >>> files, and where we have to win more by making it binary. I am pretty >>> sure this is a case where we win more by sticking to binary files. >>> It's totally fine if you disagree on this, but I'd still like to ask >>> you to think about whether your specific usecase and specific >>> requirements are strong enough to (continue to) be the default for >>> Fedora, instead of just being your local configuration of Fedora. I >>> mean, you should never forget that on your own machines everything >>> will stay as is: you will install syslog, and things will be exactly >>> as before. Lennart >> So maybe we (Fedora) should go with XML instead of binary or some >> dedicated RDMBS for storing system logs? I'm not against binary log >> format but try to understand why it's superior to text and also why >> something more sophisticated isn't used if we really need this >> additional meta data that could not be included in plain text? > With a binary format you can have an index of field -> offset, > hash->offset, etc., and then you can jump to this offset and read data > there. With text files, and with XML files, this is not possible, at > least not in any sane way. Efficiency would be much worse too. > OK, XML is also text so my alternative is a bit illusory but it could be represented as DOM nodes and could be indexed easier and more efficiently. Please, see how good is XML implementation in PostgreSQL. You can say, it's too much and too complicated for stupid system logs to go with fully blown RDBMS solution, but hey, really? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 5:32 AM, Matthew Garrett wrote: > On Thu, Jul 11, 2013 at 11:58:08PM -0400, Matthew Miller wrote: >> On Thu, Jul 11, 2013 at 11:50:24PM -0400, Rahul Sundaram wrote: >> > > Or does it mean x86 as PA is out of line? There are a lot more people >> > > with ARM devices than x86. Sorry everybody, we're going to have to >> > > demote >> > > x86. ;-) >> > False marketing. Majority of ARM devices out there don't run Fedora and >> > never will. >> >> Sooner or later, though, we probably _should_ deemphasize 32-bit x86. > > The website already links to 64-bit in preference to 32-bit. There's > arguably reasons to prefer 32-bit in certain memory-constrained > environments, but there's certainly arguments in favour of (say) > dropping most of the 32-bit x86 package set and turning it into a > specialised subset of the overall distribution. So sat make it a secondary arch? Not sure how you can be promoting "specialised subset of the overall distribution" for x86-32 and saying that ARM must support 100% of what mainline currently does! I personally would be against demoting the x86 32 bit experience for the general user but in terms of specialist packages there's already a delta between x86-32 and 64 in mainline Fedora. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 05:41:38PM -0400, Matthew Miller wrote: > On Mon, Jul 15, 2013 at 04:38:29PM -0500, Chris Adams wrote: > > And, despite your statement to the contrary, "journalctl" (without -f) > > does truncate long lines. The difference is that "journalctl" just > > chops them off, while "journalctl -f" does the nutty "chop characters > > columns-4 to linelength-1 and replace them with dots" bit. > Ooh. Yeah, journalctl -f shouldn't do that. That makes it a lot less useful. https://bugzilla.redhat.com/show_bug.cgi?id=984758 -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Mon, Jul 15, 2013 at 5:25 PM, Peter Robinson wrote: > On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy wrote: >> On 07/11/2013 10:41 AM, Bill Nottingham wrote: >>> >>> Kernel, glibc, all the core library stacks. And I would argue that yes, >>> this >>> *includes* libGL. So llvmpipe needs fixed, outside of any desktops. >>> Should >>> we define the core functionality better? Probably. >> >> >> I would argue that it does not include libGL because it's not a requirement >> for headless deployment scenarios. Why would you argue for it? > > I would argue that it's nothing to do with headless scenarios but more > that the vast majority of ARM GPUs support GL-ES which is a > sub/different standard of desktop GL (sorry, I'm not a graphics > programming expert!) and the support for that in mesa and in general > is terrible. There was a proposal to refactor mesa and when I spoke to > ajax (I think, sorry ajax if it wasn't you) or someone it wasn't > basically moving forward upstream at the moment. I'm not sure who > originally was driving this (my google fu doesn't give me the mailing > list proposal ATM). It is getting a bit off the topic, but this it isn't really a problem with mesa. But rather that we have non-gallium closed src drivers from the GPU vendors in the ARM space, which only support GLES. And most/all of the desktop stuff packaged in fedora (in particular, gnome-shell) is requiring GL. The desktop gallium mesa drivers, and also the intel mesa driver, all seem to support both GL and GLES reasonably well.. From a hw standpoint, while they may lack some features compared to desktop GPU, I think all the current mobile GPUs should support enough features in hardware to get gnome-shell running (possibly with some driver tricks, for example in freedreno I have to emulate quads with triangles). It wouldn't be enough for passing any GL compliance suite, but the requirements for gnome-shell are fairly basic. BR, -R > Peter > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 07/15/2013 09:26 PM, Jonathan Masters wrote: On Jul 15, 2013, at 5:11, Miroslav Suchý wrote: On 07/15/2013 10:44 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: No Default Syslog = https://fedoraproject.org/wiki/Changes/NoDefaultSyslog Change owner(s): Lennart Poettering , Matthew Miller No longer install a traditional syslog service by default. (Specifically, remove rsyslog from the @core or @standard groups in comps.) The systemd journal will be the default logging solution. Rsyslog, Syslog-NG, and even traditional sysklogd will continue to cover use cases outside of the default. My voice may be one of thousands, but I'm saying: I want to have traditional syslog service as default and have journal from systemd as option. I concur. I have systems that live in a heterogeneous environment and need traditional syslog. By making it optional, it will ultimately die, forcing journal as the only viable option in a Fedora environment. This is IMO not net beneficial for downstream use cases later on either. Has syslog-ng entirely died since rsyslogd has been the default? Anyway there really is no point in installing and running two loggers on embed/server/desktop wasting ram,diskspace and cpu cycles *for everybody* instead of administrators simply adding rsyslog or syslog-ng manually at install time or to their ks snippets. Nobody is talking about removing from the distribution entirely and quite frankly administrators that complain about journal have not actually tried it and experienced the flexibility the journactl gives them it truly is not as bad as some people are trying to make it out to be. And honestly I dont understand why people are ack/nack-ing this since this is FESCO decision and actually with my QA hat on we could have been better prepared for this and worked to our advantage ( instead of be dealing with potential breakage afterwards) and would have done so when I submitted [1] but apparently such work flow are forbidden by FESCO/FPC in the project. JBG 1. https://fedoraproject.org/wiki/Features/systemd-journal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 17:26, Jonathan Masters (j...@redhat.com) wrote: > >> The systemd journal will be the default logging solution. Rsyslog, > >> Syslog-NG, > >> and even traditional sysklogd will continue to cover use cases outside of > >> the > >> default. > > > > My voice may be one of thousands, but I'm saying: I want to have > > traditional syslog service as default and have journal from systemd as > > option. > > I concur. I have systems that live in a heterogeneous environment and > need traditional syslog. By making it optional, it will ultimately > die, forcing journal as the only viable option in a Fedora > environment. This is IMO not net beneficial for downstream use cases > later on either. I figure by "making it optional" you actually mean "not installing it by default"? What kind of logic is this? So everything that we don't install by default dies? That is a very weird idea. There are tons of packages in Fedora that are not installed by default and very healthy. I mean, what's next, you suggest to install Apache or MariaDB by default because otherwise "they die"? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 3:46 PM, Lennart Poettering wrote: > But this specific usecase certainly warranted this, and the > journal does deliver the requirements we cared for. I'm sure it does. But I think those requirements mainly apply to servers and enterprise installations, not the average Fedora installation. For the most common use case, doing without /var/log/messages just makes things more complicated for the user and/or sysadmin. I'm all for being able to get fancy binary journals as a configurable option. Or even by default, as long as it doesn't take away also getting a text log by default as well. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 11:38:14PM +0200, Mateusz Marzantowicz wrote: > On 15.07.2013 23:06, Lennart Poettering wrote: > > It's a matter of finding the right balance: i.e. what can be text > > files, and where we have to win more by making it binary. I am pretty > > sure this is a case where we win more by sticking to binary files. > > It's totally fine if you disagree on this, but I'd still like to ask > > you to think about whether your specific usecase and specific > > requirements are strong enough to (continue to) be the default for > > Fedora, instead of just being your local configuration of Fedora. I > > mean, you should never forget that on your own machines everything > > will stay as is: you will install syslog, and things will be exactly > > as before. Lennart > > So maybe we (Fedora) should go with XML instead of binary or some > dedicated RDMBS for storing system logs? I'm not against binary log > format but try to understand why it's superior to text and also why > something more sophisticated isn't used if we really need this > additional meta data that could not be included in plain text? With a binary format you can have an index of field -> offset, hash->offset, etc., and then you can jump to this offset and read data there. With text files, and with XML files, this is not possible, at least not in any sane way. Efficiency would be much worse too. Zbyszek -- they are not broken. they are refucktored -- alxchk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 3:45 PM, Till Maas wrote: > Oh, sorry, I was imprecise. Bash actually tells you when new mail is put > into the spool. E.g. if you log in as root, touch /var/spool/root and > wait up to 60 seconds and run e.g. ls, bash should tell you that there > is new mail before the next prompt. Sure. And how often does a typical user log in as root to discover that email? Even on systems I administer myself, I don't log in as root, or su, all that often. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 16:42, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Lennart Poettering said: > > On Mon, 15.07.13 16:38, Chris Adams (li...@cmadams.net) wrote: > > > And, despite your statement to the contrary, "journalctl" (without -f) > > > does truncate long lines. The difference is that "journalctl" just > > > chops them off, while "journalctl -f" does the nutty "chop characters > > > columns-4 to linelength-1 and replace them with dots" bit. > > > > You are aware that you can scroll to the right in "less"? Just press the > > arrow key to the left. > > I assume you mean "arrow key to the right", but that doesn't work when I > run "journalctl". I get "No next file" (and "No previous file" for > left-arrow). Yes, to the right. You are using less as a pager I presume? Scrolling to the right certainly works here. Please file a bug against less if it doesn't for you. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 23:38, Mateusz Marzantowicz (mmarzantow...@osdf.com.pl) wrote: > On 15.07.2013 23:06, Lennart Poettering wrote: > > It's a matter of finding the right balance: i.e. what can be text > > files, and where we have to win more by making it binary. I am pretty > > sure this is a case where we win more by sticking to binary files. > > It's totally fine if you disagree on this, but I'd still like to ask > > you to think about whether your specific usecase and specific > > requirements are strong enough to (continue to) be the default for > > Fedora, instead of just being your local configuration of Fedora. I > > mean, you should never forget that on your own machines everything > > will stay as is: you will install syslog, and things will be exactly > > as before. Lennart > > So maybe we (Fedora) should go with XML instead of binary or some > dedicated RDMBS for storing system logs? I'm not against binary log > format but try to understand why it's superior to text and also why > something more sophisticated isn't used if we really need this > additional meta data that could not be included in plain text? XML and text files are not sanely indexable. Real database are large packages we cannot pull into minimal systems. Beyond that, and that's most important: the specific requirements are different from what those systems provide. We want something minimal, C-based, that can work without any service around, that can be mmapped by multiple processes at the same time. Something that indexes implicitly by all keys without any pre-defined schema. Something that primarily append-only (for robustness reasons). Something that is indexed by time, and interleavable. Something that can store binary blobs, that can optionally compress larger blobs. Something that can be rotated. Something that supports Unix access controls natively. Something that provides us with the right complexity guarantees. And more... If you create a domain-specific database, then you should not do that lightly. But this specific usecase certainly warranted this, and the journal does deliver the requirements we cared for. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 03:15:54PM -0600, Eric Smith wrote: > On Mon, Jul 15, 2013 at 3:12 PM, Till Maas wrote: > > Bash usually tells you when there is mail in the spool, which is IMHO a > > big difference to /dev/null. > > Funny, I just ssh'd into my machine, and it didn't tell me anything > about mail being in the spool, but when I do an ls on the spool > directory, there it is. > > Maybe it has something to do with that users don't often log in as root. Oh, sorry, I was imprecise. Bash actually tells you when new mail is put into the spool. E.g. if you log in as root, touch /var/spool/root and wait up to 60 seconds and run e.g. ls, bash should tell you that there is new mail before the next prompt. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 04:31:38PM -0500, Robert Nichols wrote: > So, all users on a multi-user system are now expected to dig through > syslog output to see the output from their cron jobs? What? No. If you have a traditional multiuser system you probably want to install and configure an MTA. Note that this feature is no _default_ sendmail, not "die all MTAs die". -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, Martin Langhoff said: > You might be hitting a bug, have a surprising pager envvar or > something. My general experience is that it does page things. I don't > think there's a conspiracy against your pager. I do set LESS and PAGER, but I just tried without either set, and I get the same behavior. -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 3:31 PM, Robert Nichols wrote: > So, all users on a multi-user system are now expected to dig through > syslog output to see the output from their cron jobs? A fair point, but in my experience the most common case is a single-user system where the user doesn't even use cron. I'm not sure whether that's most common in general, but if it is, I think it's acceptable to have installing an MTA as a manual step on a multiuser system where there are user cron jobs. Having the MTA installed by default on end-user systems I administer has always been problematic, which is why I always remove it. The users I've supported have never gained any benefit from having a local MTA, and normally their MUA points to a remote IMAP server, so they wouldn't ever see local email. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 8:53 PM, Adam Williamson wrote: > On Thu, 2013-07-11 at 09:17 +, "Jóhann B. Guðmundsson" wrote: > >> > I'm afraid I can't agree. I like the simplicity of the model you're >> > proposing, but from a practical point of view, there is still a commonly >> > held perception that there is a 'product' called Fedora which is >> > basically composed of what you get if you go to get.fedoraproject.org, >> > download one of the things we push at you there, and install it. >> > Practically speaking, I believe we have to QA that 'thing called Fedora' >> > as a whole. I don't think your model quite matches what people perceive >> > Fedora to be. >> >> What's your definition of what people perceive Fedora to be? > > "What do we talk about when we talk about Fedora?" :) > > Well, we just did a major release. Go look on news.google.com for > "Fedora 19", or search for "Fedora 19 review", or just poke through a > few popular tech sites and forums. > > What do people do when they want to 'try Fedora 19'? They download the > primary image on the download page, which is the desktop live, and run > it. This is what they've _always_ done. Hmm I wouldn't be surprised if we had more Fedora users running on cloud instances now than we do on the desktop but there's no way to tell really. > Do you ever see anyone doing a minimal install and commenting on the > package loadout? Commenting on the actual interesting and difficult > technical changes that are what a distribution really does? No, they run > the live image for a couple of days, decide whether they think the > desktop background looks nice, say whether they liked the installer, and > bash GNOME 3 for a while. Or they run it in the cloud where it mostly just works and they don't give a hoot about a 10 year support cycle because their spun up image in some cases barely last 10 days and get on with their job and don't say a thing :-P > If we're really, really lucky they'll mention there are some other spins > available. In passing. Without ever downloading one. And that's about > it. Agree! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, Lennart Poettering said: > On Mon, 15.07.13 16:38, Chris Adams (li...@cmadams.net) wrote: > > And, despite your statement to the contrary, "journalctl" (without -f) > > does truncate long lines. The difference is that "journalctl" just > > chops them off, while "journalctl -f" does the nutty "chop characters > > columns-4 to linelength-1 and replace them with dots" bit. > > You are aware that you can scroll to the right in "less"? Just press the > arrow key to the left. I assume you mean "arrow key to the right", but that doesn't work when I run "journalctl". I get "No next file" (and "No previous file" for left-arrow). -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 04:38:29PM -0500, Chris Adams wrote: > And, despite your statement to the contrary, "journalctl" (without -f) > does truncate long lines. The difference is that "journalctl" just > chops them off, while "journalctl -f" does the nutty "chop characters > columns-4 to linelength-1 and replace them with dots" bit. Ooh. Yeah, journalctl -f shouldn't do that. That makes it a lot less useful. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 5:38 PM, Chris Adams wrote: > And, despite your statement to the contrary, "journalctl" (without -f) Hey Chris! You might be hitting a bug, have a surprising pager envvar or something. My general experience is that it does page things. I don't think there's a conspiracy against your pager. cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 16:38, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Lennart Poettering said: > > On Mon, 15.07.13 16:31, Chris Adams (li...@cmadams.net) wrote: > > > > > Once upon a time, Lennart Poettering said: > > > > (also: journalctl doesn't truncate lines when doing auto-paging) > > > > > > It most certainly does, at least on an up-to-date F18 system. The > > > truncation behavior is even DIFFERENT between "journalctl" and > > > "journalctl -f" modes! > > > > Well, "journalctl -f" dosn't do auto-paging. "journalctl" (without -f) > > does. So here you go. > > And, despite your statement to the contrary, "journalctl" (without -f) > does truncate long lines. The difference is that "journalctl" just > chops them off, while "journalctl -f" does the nutty "chop characters > columns-4 to linelength-1 and replace them with dots" bit. You are aware that you can scroll to the right in "less"? Just press the arrow key to the left. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 04:22:43PM -0500, Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > This means that you haven't really used journalctl. It *is* much > > nicer. Try it, and you'll stop wanting to go back to 'less > > /var/log/messages' > > and 'tail -f /var/log/*'. > So I went and tried journalctl, and immediately hit the same UI > stupidity as systemctl. Truncated lines, auto-paging, etc., unless I > pipe to something else. Significantly differing behavior between direct > output and pipes is just wrong. Having to remember some double-dash > long option just to get non-truncated (and non-useless) log info is > highly irritating. What version are you looking at? Current version should not truncate lines. I think that's now fixed across all systemd commands. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, Matthew Miller said: > On Mon, Jul 15, 2013 at 04:22:43PM -0500, Chris Adams wrote: > > So I went and tried journalctl, and immediately hit the same UI > > stupidity as systemctl. Truncated lines, auto-paging, etc., unless I > > pipe to something else. Significantly differing behavior between direct > > output and pipes is just wrong. Having to remember some double-dash > > long option just to get non-truncated (and non-useless) log info is > > highly irritating. > > What version are you looking at? Current version should not truncate lines. > > I think that's now fixed across all systemd commands. Current up-to-date F18, which is systemd-201-2.fc18.7.x86_64. -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 15.07.2013 23:06, Lennart Poettering wrote: > It's a matter of finding the right balance: i.e. what can be text > files, and where we have to win more by making it binary. I am pretty > sure this is a case where we win more by sticking to binary files. > It's totally fine if you disagree on this, but I'd still like to ask > you to think about whether your specific usecase and specific > requirements are strong enough to (continue to) be the default for > Fedora, instead of just being your local configuration of Fedora. I > mean, you should never forget that on your own machines everything > will stay as is: you will install syslog, and things will be exactly > as before. Lennart So maybe we (Fedora) should go with XML instead of binary or some dedicated RDMBS for storing system logs? I'm not against binary log format but try to understand why it's superior to text and also why something more sophisticated isn't used if we really need this additional meta data that could not be included in plain text? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 17:31, Matthew Miller (mat...@fedoraproject.org) wrote: > 4) lack of current tools for attempting to recover a possibly scrambled > file Well, let's note on this one that the journal is fine with the tail-corrupted files with its default tool set. However, we have no nice tools currently for recovering for "middle" corrupted files, which however are far less likely. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, Lennart Poettering said: > On Mon, 15.07.13 16:31, Chris Adams (li...@cmadams.net) wrote: > > > Once upon a time, Lennart Poettering said: > > > (also: journalctl doesn't truncate lines when doing auto-paging) > > > > It most certainly does, at least on an up-to-date F18 system. The > > truncation behavior is even DIFFERENT between "journalctl" and > > "journalctl -f" modes! > > Well, "journalctl -f" dosn't do auto-paging. "journalctl" (without -f) > does. So here you go. And, despite your statement to the contrary, "journalctl" (without -f) does truncate long lines. The difference is that "journalctl" just chops them off, while "journalctl -f" does the nutty "chop characters columns-4 to linelength-1 and replace them with dots" bit. -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Mon, Jul 15, 2013 at 4:53 PM, Peter Robinson wrote: > On Thu, Jul 11, 2013 at 6:08 PM, Bill Nottingham wrote: >> Adam Jackson (a...@redhat.com) said: >>> If we really wanted to talk about graphics on arm, we'd be talking about >>> writing drivers for GPUs. >> >> Is there any use to shipping freedreno and similar projects in Fedora ARM >> before they get to the upstream kernel? (I expect a brickbat from Josh >> fairly quickly for suggesting this.) > > I've been following the tegra and lima (Mali 400) upstream work pretty > closely but neither is actually usable for gnome-shell yet to be > worth, IMO, even to be packaging it in a third party package. In he > case of the freedreno while the work is cool the qualcomm SoC is > primarily shipped on phones and tablets [1] which isn't our primary > focus so while would be cool to support I'm unsure what the user > experience would be like if we did ship it. Side note there is > upstream multi platform support for the MSM SoCs now but I have no > idea how complete this is (eg AllWinner MP support is upstream but > it's still only core SoC/serial/mmc) fwiw, there are a few boards. Various iterations of dragonboard[1].. much cheaper than the pre-low-cost-community-board dev-boards of years gone by, but still a little bit on the pricey side. And then there is the inforce ifc6410[2] which is what the dragonboard should have been all along. Sadly it seems the devicetree support (which would be needed for multi-platform) is coming in newer SoC's than the apq8064. Or older (s3/msm8660). So for out of the box multi-platform fedora kernel, I think we are talking about some eventual successor to the ifc6410 board. I should note that the freescale iMX5.x devices also have an adreno a200 GPU.. which I've not had a chance to add support for yet, but it is on my TODO list somewhere. Along with a lot of other things. Although I'm not sure that I'd want to try to run gnome-shell at 1080p on this one. BR, -R [1] http://mydragonboard.org/ [2] http://www.inforcecomputing.com/product/moreinfo/ifc6410.html > Peter > > [1] I've seen one dev board > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 16:31, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Lennart Poettering said: > > (also: journalctl doesn't truncate lines when doing auto-paging) > > It most certainly does, at least on an up-to-date F18 system. The > truncation behavior is even DIFFERENT between "journalctl" and > "journalctl -f" modes! Well, "journalctl -f" dosn't do auto-paging. "journalctl" (without -f) does. So here you go. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 03:12:00PM -0600, Eric Smith wrote: > /var/log/messages that I don't want to see it go away. It's far > easier for me to tell someone a grep command on the phone than to also > have to tell them to run some other tool and pipe the input into grep, I think actually the journalctl filtering commands are more phone-friendly than grep. This might fall under "try it -- you might like it!". -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 15:28, Eric Smith (brouh...@fedoraproject.org) wrote: > On Mon, Jul 15, 2013 at 3:21 PM, Lennart Poettering > wrote: > > (But > > really, the comparison is just wrong, since the registry is a > > configuration store, and not a log store.) > > It's not a perfect analogy, yet the arguments for both seem very > similar, which is why I brought it up. We should try to learn from the > mistakes made by other systems, rather than rushing to repeat them. > > Microsoft uses binary logs also, and they are really awful. Maybe > your binary journal is far better than MS' logs, but all the > arguments I've seen for it so far make it seem like the advantages are > mainly for complex use cases, and for those someone is going to do a > bunch of system configuration work anyhow, so it doesn't make sense > for that to be the default. The default should be simple, and the > configuration should be done if you want something complex, rather > than the other way around. Showing the last 10 log lines for "systemctl status" is not a "complex usecase". Quite frankly, seeing the most recent log output of a service is certainly the most relevant information when you are wondering about a service's state. There is no efficient, correct way how you could implement that on top of /var/log/messages. journalctl makes things easier, not more complex. Sure, you have to learn a new tool, but the level is low for this one, and you will gain a lot more out of it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On 07/15/2013 04:17 PM, Eric Smith wrote: On Mon, Jul 15, 2013 at 3:14 PM, Till Maas wrote: But the information cron sends via email is usually more important than the regular log entries, because output in cron jobs usually means there is an error. It seems wrong to store the important data hidden among less important data. Then the syslog severities are configured wrong. That's not a good justification for using email rather than syslog. So, all users on a multi-user system are now expected to dig through syslog output to see the output from their cron jobs? And of course, syslog output will now be stored somewhere that is, by default, world readable, right? -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, Lennart Poettering said: > (also: journalctl doesn't truncate lines when doing auto-paging) It most certainly does, at least on an up-to-date F18 system. The truncation behavior is even DIFFERENT between "journalctl" and "journalctl -f" modes! -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 02:53:06PM -0600, Eric Smith wrote: > But it's what people actually use in 99.9% of cases. 99.9% of the > time I don't need the extra information in the binary journal. Making > /var/log/messages unavailable by default has a huge down side. We should probably refrain from hyperbole on either side. It has 1) a training/learning cost because the tools are different 2) an inconvenience when the tools aren't easily available 3) a rare real case where no _tools_ are available but the system is partially live and you have no-off-system logging and you can't reboot into a diagnostic tools environment or take the disk offline 4) lack of current tools for attempting to recover a possibly scrambled file 5) early-adopter risk that the code is more fragile than expected and has unknown serious corruption cases Have I missed something? I'd rather see a structured text format, but I understand that that's computationally expensive. At least the binary format is a) simple and b) documented. http://www.freedesktop.org/wiki/Software/systemd/journal-files/ -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/15/2013 11:09 AM, Bill Nottingham wrote: If I'm understanding you, you would prefer that ARM be blessed with the stamp of being a 'primary' arch at the cost of dropping release targets, images, and featuresets that are made by and for the community now. I wouldn't put it like that. The ARM team isn't asking for a blessing, we're asking to have builds that block ARM also block x86. At a technical level, that is a fundamental part of what being primary is. Yes, there are other aspects, both practical (what is released) and philosophical (What is Fedora). It's the next logical step. If not now, when? When libGL is ready to go? I don't think I can support that - it seems awfully unfriendly to the community that exists now. You are proceeding from a misconception: This is a thought exercise- If ARM devices didn't have graphics would it still be essential for PA promotion that libGL for ARM work and be accelerated? There is no proposal to throw out the baby or the bathwater. This is about defining the threshold at which point armv7hl gets built along side i686 and x86_64. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 3:21 PM, Lennart Poettering wrote: > (But > really, the comparison is just wrong, since the registry is a > configuration store, and not a log store.) It's not a perfect analogy, yet the arguments for both seem very similar, which is why I brought it up. We should try to learn from the mistakes made by other systems, rather than rushing to repeat them. Microsoft uses binary logs also, and they are really awful. Maybe your binary journal is far better than MS' logs, but all the arguments I've seen for it so far make it seem like the advantages are mainly for complex use cases, and for those someone is going to do a bunch of system configuration work anyhow, so it doesn't make sense for that to be the default. The default should be simple, and the configuration should be done if you want something complex, rather than the other way around. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 16:22, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > This means that you haven't really used journalctl. It *is* much > > nicer. Try it, and you'll stop wanting to go back to 'less > > /var/log/messages' > > and 'tail -f /var/log/*'. > > So I went and tried journalctl, and immediately hit the same UI > stupidity as systemctl. Truncated lines, auto-paging, etc., unless I > pipe to something else. Significantly differing behavior between direct > output and pipes is just wrong. Having to remember some double-dash > long option just to get non-truncated (and non-useless) log info is > highly irritating. You can set SYSTEMD_PAGER to the empty string to turn off auto-paging in all systemd tools. There's a bug against bash that requests adding a (commented) line to .bash_profile, so that the auto-pager haters can easily disable this behaviour, just by uncommented that line. But this is a really different discussion anyway. I know some people hate auto-paging, but I am pretty sure more people learned to love it since it was introduced by git. I love auto-paging for sure. Lennart (also: journalctl doesn't truncate lines when doing auto-paging) -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?
On Wed, 2013-05-22 at 05:18 -0400, Martin Sivak wrote:
> > One thing that doesn't seem to have been covered in the discussion —
> > what about third-party firstboot modules?
> >
> > For an install on a corporate machine we have a firstboot module which
> > asks for the Active Directory credentials, joins the Samba domain,
> > obtains SSL certificates for VPN and WPA2-enterprise wifi and provisions
> > those in NetworkManager, adds a local user with the appropriate
> > username, provisions accounts in Evolution-EWS and pidgin-sipe, etc.
> >
> > With firstboot gone, what form should our plugin take?
> >
>
> Firstboot stays available in RHEL for this reason (legacy plugins).
> Fedora modules will probably have to be updated. At least that was the
> plan. It is very easy to write a new module with the new API. Ping
> vpodzime, he has a development guide.
Thanks. Delayed response... I've finally got everything else working
nicely on Fedora 19 and I'm looking at this. I see firstboot is still
available, but it doesn't seem to *work*.
First it wants python-ethtool to be installed but didn't have the
appropriate dependency, and then it's still using pygtk while my own
code has been updated to pygobject and gtk3. (Which was done because
some other code I was *importing* had been upgraded, so I couldn't mix
the two. I don't think you get far with pygtk these days, do you?)
So I'm guessing that it's probably not worth looking at firstboot any
harder, and I should proceed straight to using initial-setup.
The UI part of my tool is a separate python module which can run
standalone too. The firstboot module is therefore fairly trivial, and
looks like this. Any pointers on converting to initial-setup would be
much appreciated. I note /usr/share/initial-setup/modules/README.txt is
a zero-length file... :)
#
# Xu Li
# Chris Lumens
#
# Copyright 2009 Intel Corp.
# Copyright 2008 Red Hat, Inc.
#
# This copyrighted material is made available to anyone wishing to use, modify,
# copy, or redistribute it subject to the terms and conditions of the GNU
# General Public License v.2. This program is distributed in the hope that it
# will be useful, but WITHOUT ANY WARRANTY expressed or implied, including the
# implied warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along with
# this program; if not, write to the Free Software Foundation, Inc., 51
# Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Any Red Hat
# trademarks that are incorporated in the source code or documentation are not
# subject to the GNU General Public License and may only be used or replicated
# with the express permission of Red Hat, Inc.
#
from gi.repository import Gtk, GObject
import os, string, sys
from firstboot.config import *
from firstboot.constants import *
from firstboot.functions import *
from firstboot.module import *
import logging
log = logging.getLogger("firstboot")
import gettext
_ = lambda x: gettext.ldgettext("firstboot", x)
N_ = lambda x: x
sys.path.append("/usr/share/intel-user-setup")
from iusMainWindow import iusMainWindow
class moduleClass(Module):
def __init__(self):
Module.__init__(self)
self.priority = 99
self.sidebarTitle = N_("Intel User Setup")
self.title = N_("Intel User Setup")
self.icon = ""
self.ius = None
self.needreboot = False
def apply(self, interface, testing=False):
if testing:
return RESULT_SUCCESS
try:
rc = self.ius.apply()
if rc == True:
# This should make it jump over the *normal* create_user page
interface.moveToPage(pageNum = interface._control.currentPage +
1)
self.needreboot=True
return RESULT_SUCCESS
else:
return self.showRetryDialog()
except Exception, e:
return self.showRetryDialog()
def createScreen(self, interface=None):
log.info("Display Intel user setup screen")
self.vbox = Gtk.VBox(spacing=5)
self.ius = iusMainWindow()
self.vbox.pack_start(self.ius.firstboot_widget(), False, False)
def initializeUI(self):
self.ius.local_users()
def showRetryDialog(self):
dlg = Gtk.MessageDialog(None, 0, Gtk.MESSAGE_ERROR, Gtk.BUTTONS_NONE,
"Intel user setup failed!")
dlg.add_button("Back", RESULT_FAILURE)
dlg.add_button("Ignore", RESULT_SUCCESS)
dlg.set_position(Gtk.WIN_POS_CENTER)
dlg.set_modal(True)
rc = dlg.run()
dlg.destroy()
return rc
def needsReboot(self):
return self.needreboot
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Jul 15, 2013, at 5:11, Miroslav Suchý wrote: > On 07/15/2013 10:44 AM, Jaroslav Reznik wrote: >> = Proposed System Wide Change: No Default Syslog = >> https://fedoraproject.org/wiki/Changes/NoDefaultSyslog >> >> Change owner(s): Lennart Poettering , Matthew >> Miller >> >> No longer install a traditional syslog service by default. (Specifically, >> remove rsyslog from the @core or @standard groups in comps.) >> >> The systemd journal will be the default logging solution. Rsyslog, Syslog-NG, >> and even traditional sysklogd will continue to cover use cases outside of the >> default. > > My voice may be one of thousands, but I'm saying: I want to have traditional > syslog service as default and have journal from systemd as option. I concur. I have systems that live in a heterogeneous environment and need traditional syslog. By making it optional, it will ultimately die, forcing journal as the only viable option in a Fedora environment. This is IMO not net beneficial for downstream use cases later on either. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why can't ExecStopPre= be used to abort stopping a (broken) service?
On 07/15/2013 08:55 PM, Lennart Poettering wrote: On Mon, 15.07.13 14:18, Paul Wouters (pwout...@redhat.com) wrote: Hi, For daemons, it happens that people (or puppet/ansible) makes a config change that causes the config file to not load and be invalid. When restarting the service, it will stop but not start. Ideally, the stop should be aborted. I was looking at ExecStopPre= (which is mentioned in the systemd.service man page, although it does not have its own section, so is easilly missed) but it did not abort the stop on a parse error in the daemon's config file. I found this note by Lennart: http://osdir.com/ml/fedora-devel-list/2011-05/msg00696.html No, ExecStopPre= cannot be used for making shutdown of a service conditional. Even if one of the pre lines fails we will go on with shutting down the service, however we will store the exit code and the service will be in "failed" state once fully shut down. My question is, why not? Various daemons (libreswan, bind, knot, nsd, etc) have a "check config" option that could be used to prevent stopping a service if the config file got messed up so it would prevent the service from starting. I realise that it is not optimal to keep a service running that will fail to restart on the next machine boot, but is that preferable over failing immediately? If ExecStopPre= would fail and log a message, sysadmins would be able to notice the issue and fix it. And there would be 0 downtime. As opposed to the current behaviour, which kills the service. However, if ExecStopPre= would support this, then every maintainer could choose for themselves which situation is preferred. If I grok correctly what you are asking for, you are actually looing for an ExecRestartPre=, not an ExecStopPre=. You want somthing that is run before we stop a service when we intend to restart it. But when we shutdown the system and stop the service for that, or if the user wants to stop it manually, we shouldn't run it, correct? If that's what you want, then yes, it is on the TODO list to add something like this, but ExecStopPre= is not what you want, it would have very different semantics. Adding that does not make much sense. For the first in 99% use cases are covered via ExecStartPre= based on how this was handle in the legacy sysv init scripts. Secondly the fact is that the admin would never notice the configuration error because he Admin makes incorrect change to config file --> then restart the service --> the service would not fail since it would be caught by either ExecStopPre= or ExecRestartPre= ( which I dont see the need for ) --> he then checks if the service is running ( which it will be since it never got restarted or stopped/started like most of the legacy sysvinit script did ) --> he then scratches his head why the changes he made were not applied. The fact is the only way admin will notices and react to this, is if the service will hard fail upon restart and systemd should not be working around admin mistakes in configuration file. The correct way here is to stay true to what is tried and tested in the legacy sysv init scripts and add the config parser to the ExecStartPre= line in the unit file. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 7:40 PM, Brendan Conoboy wrote: > On 07/11/2013 10:41 AM, Bill Nottingham wrote: >> >> Kernel, glibc, all the core library stacks. And I would argue that yes, >> this >> *includes* libGL. So llvmpipe needs fixed, outside of any desktops. >> Should >> we define the core functionality better? Probably. > > > I would argue that it does not include libGL because it's not a requirement > for headless deployment scenarios. Why would you argue for it? I would argue that it's nothing to do with headless scenarios but more that the vast majority of ARM GPUs support GL-ES which is a sub/different standard of desktop GL (sorry, I'm not a graphics programming expert!) and the support for that in mesa and in general is terrible. There was a proposal to refactor mesa and when I spoke to ajax (I think, sorry ajax if it wasn't you) or someone it wasn't basically moving forward upstream at the moment. I'm not sure who originally was driving this (my google fu doesn't give me the mailing list proposal ATM). Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, 15.07.13 23:14, Till Maas (opensou...@till.name) wrote: > On Mon, Jul 15, 2013 at 04:14:35PM +0200, Lennart Poettering wrote: > > > This feature is about not doign local mail delivery by default, by not > > installing any MTA. Instead you find the log output of cronjobs at the > > same place as you find any other log output, the journal/syslog, for > > example accessible via: > > > > journalctl -u crond > > But the information cron sends via email is usually more important than > the regular log entries, because output in cron jobs usually means there > is an error. It seems wrong to store the important data hidden among > less important data. journalctl helps you with that too: "journalctl -p notice" will output all messages of log level "notice" and higher, which is the stuff that matters, and what you really should look at. And even if you do not pass this to journalctl you will get the important lines highlighted bold and the really important ones red, so it should be really easy to find the output that matters. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, Zbigniew Jędrzejewski-Szmek said: > This means that you haven't really used journalctl. It *is* much > nicer. Try it, and you'll stop wanting to go back to 'less /var/log/messages' > and 'tail -f /var/log/*'. So I went and tried journalctl, and immediately hit the same UI stupidity as systemctl. Truncated lines, auto-paging, etc., unless I pipe to something else. Significantly differing behavior between direct output and pipes is just wrong. Having to remember some double-dash long option just to get non-truncated (and non-useless) log info is highly irritating. -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, 15.07.13 15:14, Eric Smith (brouh...@fedoraproject.org) wrote: > On Mon, Jul 15, 2013 at 3:06 PM, Lennart Poettering > wrote: > > On Mon, 15.07.13 14:53, Eric Smith (brouh...@fedoraproject.org) wrote: > >> If we go to having only binary logs by default, maybe we should also > >> go to having only binary configuration files by default. It's > >> basically the same arguments: there's more information available; it's > >> easier for software to parse; it can be made more reliable; special > >> tools are OK and people don't really need to open it in a text editor. > >> We've seen how well that works on Windows. Blech. > > > Nobody is proposing this. > > Nobody is seriously proposing it, yet no one has given much > explanation of why binary-only logs are better than text logs that > isn't essentially the same as the arguments for the Windows Registry. Well, indexing, structure, sealing are some reasons for using binary journal files. The registry isn't particularly good at any of this. (But really, the comparison is just wrong, since the registry is a configuration store, and not a log store.) But I mean, honestly, in all fairness, even if the Registry might be an awful mess, there actually are valid reasons for the existance of the registry too, regardless whether they might be convincing or not. Just because something is a reason for having a binary configuration store it doesn't invalidate the reason for having a binary index log store... And again, nobody is talking about introducing binary configuration stores, that's another straw-man of yours. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 3:14 PM, Till Maas wrote: > But the information cron sends via email is usually more important than > the regular log entries, because output in cron jobs usually means there > is an error. It seems wrong to store the important data hidden among > less important data. Then the syslog severities are configured wrong. That's not a good justification for using email rather than syslog. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 7:22 PM, Peter Jones wrote: > On Thu, Jul 11, 2013 at 10:58:59AM -0700, Brendan Conoboy wrote: > >> Security features are implemented and working- except >> evidently pointer guards, which we found out about *yesterday*. > > The point of this isn't just that it was broken, though - the concern > here is that the test suite said it was not working. What else isn't > working because nobody has even looked? What's worrisome here is not > merely that a major security feature wasn't working. While that is > troubling, the fact of the matter is that people *not* on your team > thought it wasn't working, and assumed that you knew. The test suite > is giving failing results. That's not usually an indicator of high > quality or success. Can you link to these test suite failures? In all cases I would expect that make check would fail and hence the package would fail to build but I've seen issues on x86 as well where the "test results" are logged but ignored. I'm fully aware ARM isn't perfect here because in the early time of bring up we've needed to disable some tests during bring or to move things forward while upstream bugs are fixed up but I've usually filed bugs to track the issue to ensure that things are reverted on resolution. > The worry isn't that there's one thing here or there that doesn't work - > the worry is that there are relatively major Fedora features that we've > advertised in big letters in the relatively recent past that simply > don't work because nobody has paid any attention to whether or not they > work. Are you aware of others other than fstack-protector? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 3:12 PM, Till Maas wrote: > Bash usually tells you when there is mail in the spool, which is IMHO a > big difference to /dev/null. Funny, I just ssh'd into my machine, and it didn't tell me anything about mail being in the spool, but when I do an ls on the spool directory, there it is. Maybe it has something to do with that users don't often log in as root. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 3:06 PM, Lennart Poettering wrote: > On Mon, 15.07.13 14:53, Eric Smith (brouh...@fedoraproject.org) wrote: >> If we go to having only binary logs by default, maybe we should also >> go to having only binary configuration files by default. It's >> basically the same arguments: there's more information available; it's >> easier for software to parse; it can be made more reliable; special >> tools are OK and people don't really need to open it in a text editor. >> We've seen how well that works on Windows. Blech. > Nobody is proposing this. Nobody is seriously proposing it, yet no one has given much explanation of why binary-only logs are better than text logs that isn't essentially the same as the arguments for the Windows Registry. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 04:14:35PM +0200, Lennart Poettering wrote: > This feature is about not doign local mail delivery by default, by not > installing any MTA. Instead you find the log output of cronjobs at the > same place as you find any other log output, the journal/syslog, for > example accessible via: > > journalctl -u crond But the information cron sends via email is usually more important than the regular log entries, because output in cron jobs usually means there is an error. It seems wrong to store the important data hidden among less important data. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 01:57:37PM -0400, Matthew Miller wrote: > On Mon, Jul 15, 2013 at 01:50:47PM -0400, DJ Delorie wrote: > > I worry about the security implications of mail that would have gone > > to root@ being either silently discarded or unknowingly ignored. > > That *is* the current case on these systems. The mail happens to live in > /var/spool/mail/root, where it accumulates silenty, but the difference > between that and /dev/null is practically small. Bash usually tells you when there is mail in the spool, which is IMHO a big difference to /dev/null. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 3:06 PM, Lennart Poettering wrote: > It's a matter of finding the right balance: i.e. what can be text files, > and where we have to win more by making it binary. I am pretty sure this > is a case where we win more by sticking to binary files. It's totally > fine if you disagree on this, but I'd still like to ask you to think > about whether your specific usecase and specific requirements are strong > enough to (continue to) be the default for Fedora, instead of just being > your local configuration of Fedora. > > I mean, you should never forget that on your own machines everything > will stay as is: you will install syslog, and things will be exactly as > before. I have thought a lot about usecases, and it's exactly because I have to maintain other people's systems that use the default installation, and I routinely have to use more, less, cat, grep, vi, etc. on /var/log/messages that I don't want to see it go away. It's far easier for me to tell someone a grep command on the phone than to also have to tell them to run some other tool and pipe the input into grep, or into a temp file that I can have them look at in an editor. /var/log/messages is there, it works, and it is BETTER than a binary format even if it doesn't contain as much information. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
