Re: sos's builds started to fail in Fedora rawhide
On Mon, Aug 14, 2017 at 08:31:12AM +0200, Sandro Bonazzola wrote:
> Hi, just seen that sos package is starting to fail on rawhide with
> following error:
>
>
> Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb
> --target noarch --nodeps /builddir/build/SPECS/sos.spec'] with env
> {'PS1': ' \\s-\\v\\$ ', 'SHELL': '/bin/bash', 'HOME':
> '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'TERM': 'vt100',
> 'LANG': 'en_US.UTF-8', 'PROMPT_COMMAND': 'printf
> "\\033]0;\\007"', 'HOSTNAME': 'mock'} and shell False
> py3_install: invalid option -- '-'
> error: Unknown option - in py3_install()
> error: line 35: %py3_install '--install-scripts=%{_sbindir}'
>
>
> Is something changed in python macros?
Nothing has changed in sos since February (pre-3.4). Since this only
fails on Rawhide I would expect it's a Fedora change.
The only thing that seems obviously strange is that the option is
enclosed in single quotes: the script appears to be parsing something
as "-- -" (since it complains about an option '-').
Bryn.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Draft Product Description for Fedora Workstation
On 11/04/2013 11:32 AM, Mateusz Marzantowicz wrote: Just see how others does this. Linux Kernel is one example, Django is another. This two projects from very different corners are able to provide stable API/ABI for some longer time period. I really appreciate The kernel does not provide stable APIs. If you've ever tried to maintain a non-trivial module or patch to the kernel out-of-tree for any length of time you'll understand how much work is involved in just keeping it working. Gnome shell extensions are not so different. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora minimal install no tar tool?
On 08/07/2013 04:12 PM, Bill Nottingham wrote: Adam Williamson (awill...@redhat.com) said: On Tue, 2013-07-30 at 17:23 -0400, Douglas Schilling Landgraf wrote: I have installed Fedora 17/18/19 (selected Minimal installation) from DVD and it completed successfully, however there is no tar tool. Was this change intentional? Thoughts? Why do you say 'change'? From a quick look in comps, tar has never been in the 'minimal' group (which was called @base up until a few releases ago and is now called @core). Formerly, it was pulled in by 'sos' in base/standard - it's now explicitly listed there. The sos spec file still lists tar as a dependency. This is actually false now as we're using the python TarFile class instead. Does this mean that sos is no longer in base/standard? Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Hard link to root-owned file now fails (since Fedora 19)
On 07/16/2013 12:41 PM, Colin Walters wrote: On Tue, 2013-07-16 at 10:42 +0100, Richard W.M. Jones wrote: FWIW this change caused a segfault in OpenStack This phrase is very dramatic. I'd say triggered a double free in an untested libguestfs error path is more accurate and less dramatic. Or: uncovered a pre-existing bug that could then be addressed.. Not sure how that is a bad thing. Really it had nothing to do with hard links at all - the same symptom could have happened on ENOSPC for write(). Quite. Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/2013 10:09 PM, G.Wolfe Woodbury wrote: This is simply not true. There are hundreds of thousands of older desktops that are not technically servers that have lots of older interfaces. Evidence is better than unsupported claims. Although smolt has been retired for some time now it may be possible to use the data that was collected to get some numbers as well as a sense of how non-standards based adapters are declining in the field. To say that non-AHCI controllers don't matter is to place a dignificant barrier to use or adoption of Linux or Fedora. Nobody is saying that these controllers don't matter. What we're talking about is making something /possibly/ require the use of rescue media where it hasn't since F12 (but always did previously when this hardware was much more common). I suspect that working in a situation where one is not buying or maintaining ones own computer has produced a newrsighted view of what the computing ecoshpere has lurking in it. I buy and maintain my own systems as I guess do most people interested enough in Linux to be working on it full time. Certainly for commercial Linux users I think this set is now vanishingly small (although obviously there is a much broader range of high-end storage adapters to contend with). Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEI+f0ACgkQ6YSQoMYUY96cXACgpxs8kAwjd6S4a14AQj86044I cwsAoKiegAxvFWYpNS6VMjypQqfCy02P =Yy0L -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:
On 01/29/2013 03:24 PM, Simo Sorce wrote: Wow this brings me back to Windows 95/XP antifeatures where changing hardware even a little bit strands you to not be able to boot and having to go to rescue mode. Actually this is how mkinitrd/nash worked by default for many years (pre-dracut, i.e. RHL-mumble.mumble all the way up to RHEL5). Why are we doing this ? Is this just to boot a little bit faster ? It made a considerable difference with grub1 as the bootloader had to load the image via prehistoric IO routines. I didn't think that had changed much with the move to grub2 but have not measured it. It also consumes dramatically more space on /boot which was one cause of user frustration with preupgrade (which admittedly was ever so slightly greedy about /boot space). I rebuilding is an issue, wouldn't it make sense to pre-generate the rescue initramfs at kernel build time ? Does it really need to be regenerated at install time ? Since by definition it's not system-specific I think this would be preferable. I've heard users ask for the ability to install the rescue CD in the past (and have hacked it up to do so via PXE images in /boot and a grub entry). This sounds like it would offer similar capabilities. So in summary, can we rather keep the current behavior by default and give the option to boot faster only to people that are interested in it ? The new is the old and honestly it very rarely caused problems. Also, it's not simply hardware but also software and configuration changes that may mandate updating the initramfs. We can possibly cover some bases on the hardware and updates front but even these have very difficult cases (e.g. system is shut down, hardware changed, started up - initramfs is not updated, how do we proceed?). Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:
On 01/29/2013 03:45 PM, Simo Sorce wrote: I guess it was in the short while I switched to Ubuntu, because from my memory I used to change hardware on my machines and always be extremely happy at how Linux was resilient to hardware changes between boots and automatically detected new hardware without the dreaded rescue mode. I believe mkinitrd behaved this way before there was an Ubuntu so I'd be surprised (at least RHL7/8/9, probably earlier: I was just a user until RHL7 days). The thing is that stuff in the initramfs only matters if you need it for booting. Added a new sound card? Great! We'll get to it when we have a root fs. New network card? Well, as long as you're not trying to boot an iSCSI volume over it that shouldn't be a problem either etc. Yes but is /boot space still an issue these days ? Hard to say; it isn't for me but that's because I always make them large enough for my expected uses. Do we still need a separate /boot at all ? Yes afaik. There are still some device types that are problematic without it (do the boot loaders support native LUKS/dmcrypt now?). Disks are huge these days. And speed is still an issue with modern SSDs ? I don't have any so I can't tell you but it should be easy enough to test. I wouldn't expect a massive improvement though. This are the 2 cases I have in mind: 1. Machine breaks - change motherboard - boot breaks This should not break your boot unless the storage adapters are wildly different (most things just use AHCI and are happy now). 2. Swap disk to other laptop - boot breaks Again, unless you have very different storage controllers this will not break. I really don't want or need every FC HBA kernel module, firmware bin file or other junk in my laptop initramfs just in case I happen to swap the disk to a laptop with built-in fibre-channel :-). If I was moving a disk to such radically different hardware I'd be able to prep it in advance (and I think that's 'advanced' enough that it's reasonable to expect a little user knowledge). Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On 01/29/2013 04:32 PM, Nicolas Mailhot wrote: In a Fedora context, when you do this it's because the old motherboard failed unexpectedly, you bought a new one. It's a great relief to see plugging the old drive on the new mobo just works. There is no prep in advance and old and new mobo have several years of difference so disk or network controllers have nothing in common. I'm not sure it's a good idea to optimize away such robustness. To be honest I found myself doing this sort of swap a lot more in the past when hardware was less reliable and I was more inclined to cobble systems together with parts found lying around the place: in those days the initrd was host-specific by default and I didn't find it a headache - much less of a headache than loading something with all the modules included on each boot. Maybe on modern hosts that's less of a concern for many users though (although I do see noticeable pauses during initramfs loading on quite a few systems with default configs). I've been switching this setting on my boxes since dracut first came in so I can carry on with or without the feature and it makes little difference. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fltk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/20/2012 12:04 AM, Adam Williamson wrote: On Thu, 2012-12-20 at 00:06 +0100, Kevin Kofler wrote: Adam Williamson wrote: On Wed, 2012-12-19 at 18:30 +0100, Miloslav Trma? wrote: Probably http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking Mirek Jeez, Ubuntu still hasn't done that? I don't think ANY other distro has done that pointless incompatible change (except those which switched to gold, which always behaves that way). It's still not the default in upstream ld. Mandriva did it some time before Fedora did, IIRC. Debian is implementing it in Wheezy: http://wiki.debian.org/ToolChain/DSOLinking Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDS7u0ACgkQ6YSQoMYUY94QwACfdzdMqeaLebrD4VxQoNKaU9OX uk4AnRjB5KB4MeKkorQ1dnQp2rySYDPi =nWsd -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fltk
On 19/12/12 15:12, Adrian wrote: -Wl,-z,relro -lfltk Which is pretty close to what you get on current Ubuntu: root@u1210-vm1:~# grep PRETTY /etc/os-release PRETTY_NAME=Ubuntu quantal (12.10) root@u1210-vm1:~# dpkg -s libfltk1.1 | head -2 Package: libfltk1.1 Status: install ok installed root@u1210-vm1:~# fltk-config --ldflags -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk should be (built from source) That might be what you get building from source but it's not what you'd get on a current Ubuntu system with their flkt packages so it seems this is not the cause of the problem you're seeing. On Fedora the following command fails: g++ -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -pipe -Wall -fexceptions -O2 -ffast-math -finline-functions -fomit-frame-pointer -DNDEBUG -g -O2 -o flrig [...] -Wl,-Bsymbolic-functions -lfltk_images -lfltk -ldl -lrt -lpthread While on Ubuntu it works (run in a similarly prep'ed source tree); something appears to be magically adding -lX11 during the link step on Ubuntu but it doesn't appear to have anything to do with the output produced by fltk-config (which is identical in terms of library link requests). Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fltk
On 19/12/12 17:30, Miloslav Trmač wrote: On Wed, Dec 19, 2012 at 6:27 PM, Bryn M. Reeves b...@redhat.com wrote: On Fedora the following command fails: g++ -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -pipe -Wall -fexceptions -O2 -ffast-math -finline-functions -fomit-frame-pointer -DNDEBUG -g -O2 -o flrig [...] -Wl,-Bsymbolic-functions -lfltk_images -lfltk -ldl -lrt -lpthread While on Ubuntu it works (run in a similarly prep'ed source tree); something appears to be magically adding -lX11 during the link step on Ubuntu Probably http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking Mirek So it seems to be down to the fact that flrig includes FL/x.H: $ fgrep 'FL/x.H' rig.cxx #include FL/x.H #include FL/x.H From FL/x.h: // These are internal fltk symbols that are necessary or useful for // calling Xlib. You should include this file if (and ONLY if) you // need to call Xlib directly. These symbols may not exist on non-X // systems. There are macros further on that use XCreatePixmap in their definition: # define fl_create_offscreen(w,h) \ XCreatePixmap(fl_display, \ (Fl_Surface_Device::surface()-class_name() == Fl_Display_Device::class_id ? \ fl_window : fl_xid(Fl::first_window()) ) , \ w, h, fl_visual-depth) So I'd say that fltk apps that use this header really do need to specify -lX11 in their own LDFLAGS as they will need these symbols directly. So it's an flrig bug. It's easy to work around: $ LDFLAGS=-lX11 ./configure make [...] $ ldd src/flrig linux-vdso.so.1 = (0x7fffccb82000) libX11.so.6 = /lib64/libX11.so.6 (0x003c7760) [...] I couldn't see where to report bugs on w1hkj.com... Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fltk
On 19/12/12 21:35, Adrian wrote: *From*: Bryn M. Reeves b...@redhat.com On 19/12/12 17:30, Miloslav Trmač wrote: Probably http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking Mirek So why does this bug not show itself on Suse, and any of the Debian based builds? They presumably haven't implemented the feature that Mirek pointed out. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On 10/09/2012 03:19 PM, Tom Hughes wrote: While less helpfully wraps your log lines at the edge of your terminal journalctl unhelpfully truncates them or, if -a is used, makes you use left/right cursor to scroll back and forth in an attempt to read the lines. Especially since it fully qualifies the host name so the actual message has barely got started by column 80. Agreed: I find this irritating too (and the default SYSTEMD_PAGER _is_ less so I'm not sure how it's being run). Setting PIPE or piping to a pager is even worse - the lines are truncated at 77 chars regardless of the term width so for now I'm running journalctl --no-pager -a | less to get wrapped lines in a pager. More importantly though, what is the equivalent of fgrep xxx /var/log/messages which is certainly pretty much the most common thing I do on my logs... I can't see any sort of searching in journalctl? journalctl | fgrep? This one is pretty fine by me tbh. The next most common thing I probably do is to load the log into vi so I can search back and forth to see matches in context, but obviously that is not something journalctl is every really going to be able to do. Your favourite pager probably can though. Less has the same mark and navigation keystrokes as vi. Although if you really do want to open in an editor you'll probably need to redirect to a file. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/17/2012 12:38 AM, Sam Varshavchik wrote: Jan Kratochvil writes: On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote: And I wouldn't be so presumptions as to state authoritatively what is or is not a bug, in something whose purpose is not known to me. Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). As documented by that man page, rather plainly, readlink(/proc/self/exe) gives you your own pathname. That's the normal state of things, if normal means anything. When that no longer holds true, that's not normal. As others have pointed out it is a normal situation that the system has to deal with; there's no escaping it on a UNIX-like OS and a developer can never depend on it not happening at random times. The pathname that is returned to readlink(2) doesn't exist in the file system (how could it?) but the proc path is still valid for IO and the inode will not be de-allocated while it is open: $ cp /bin/vim /tmp $ /tmp/vim foo $ ps ax | grep foo 8904 pts/3S+ 0:00 ./vim foo 8960 pts/4S+ 0:00 grep --color=auto foo $ rm /tmp/vim $ readlink /proc/8904/exe /tmp/vim (deleted) $ cat /proc/8904/exe /tmp/vim.out $ ll /tmp/vim.out -rw-rw-r--. 1 breeves breeves 2097656 Jul 17 09:41 /tmp/vim.out $ file /tmp/vim.out /tmp/vim.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x695009d204a46dd413af6afc12207ee5f21fabf5, stripped $ md5sum /tmp/vim.out 21f4752d9efdb68e6af1ff22b2652fde /tmp/vim.out $ md5sum /bin/vim 21f4752d9efdb68e6af1ff22b2652fde /bin/vim $ prelink -u -o - /tmp/vim.out | md5sum c9b7e38bacad0b1c5e04b6c71a5f45b9 - $ prelink -u -o - /bin/vim | md5sum c9b7e38bacad0b1c5e04b6c71a5f45b9 - If the check you need to make is is this the same binary? then surely it should fail if the binary was actually upgraded? If it was not and was simply modified by prelink then you should be able to do what you want by open(2)ing the proc path instead of readlink(2)ing it. If you're happy to accept something that's a different version of the binary then I'm not sure why you need to read the executable (what are you checking in it?). If it's just an inode number match it's hard to see what that achieves. Broken maintenance scripts, of dubiuous benefit, that randomly rewrite unrelated binaries, should be fixed. Suggest fixes. If you're doing something unusual the onus is on you to justify why the system should conform to your expectations instead of the expectations it's currently designed for. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: security repo
On 07/17/2012 03:02 AM, Paul Wouters wrote: On Tue, 17 Jul 2012, Mike Manilone wrote: I think we can create a new repo called security like Debian. Push all the security updates to it. Uhm, we have that. It is called RHEL Not quite although RHEL errata are also categorised as security, fix and feature. The data for vulnerabilities is also made available in standard formats (OVAL and CPE mappings for Red Hat products). Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/17/2012 12:01 PM, Sam Varshavchik wrote: Andrew Haley writes: Yes, it's the pathname that started this process. Yes, that pathname may point to file that no longer exists. That's UNIX. No, that's Linux with prelink installed. And a number of other common configurations for e.g. a Fedora system set to automatically apply security updates in the background. Perhaps this might be a hard concept to wrap one's brain around, but there's a quite a bit of difference between this is an exceptional event, and that's what happens when i does, versus this is now a normal occurence that, with prelink installed, and can happen to any random executable, at any time. Across the pond, I believe that there's a word to describe this: rubbish. Throwing pejoratives around doesn't change the situation. How presumptious of an executable binary, that's not world-writable, to expect that nobody's going to come around, suddenly, and delete it! What would those kids think of next… Prelink is not new. I think the fact that it's been in the distro for many years without breaking other apps that are doing this read-my-own-binary thing suggests that that is not a common idiom for UNIX programs (that's not to say it has never caused any problems but you seem to be questioning the entire design). Sure. And since gruesome car wrecks are a normal, everyday occurence, there's no reason to do anything to davoid them. That's how they always work, and anyone will just have to deal with the aftermath, without bothering to take any steps to avoid the situation in the first place, right? Adding more hyperbole and strawman arguments does not change the fact that this can and does happen on Linux and UNIX environments and that programs need to be aware of it and deal with it reasonably when it does happen. Ken Thompson once stated that if he wrote UNIX again he would spell creat with an 'e' but nobody is proposing changing that today. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 07/17/2012 12:42 PM, Sam Varshavchik wrote: … which can be used to reset the application, so that it knows that it's been updated. Because that is a common need across many packages. Apparently being notified of a prelink is not such a common need. Even if such a thing did exist it could not protect you from any other modifications to the binary if it was specific to prelinking so you would still need to handle this case to avoid bugs in your program. Maybe you would find more acceptance for a request asking for something like this rather than demanding the removal of something that has been used for many years and that has good evidence for the benefits it claims to provide? If you tell me how an app can be notified that prelink is about to rewrite it, then this would be a comparable situation. But it's not. Inotify? If you care about it in your app (and since nobody else appears to have asked for it I'd argue that's a good sign that there is not yet any justification for a general facility like this) perhaps you should look at inotify and register a watch for your executable's inode so that you can take appropriate actions? This would also deal with modifications other than prelinking. You could even make such a thing into a library that other developers could use to solve the same problem. If there's widespread need for the facility I'm sure you'd soon have plenty of users and a good justification to get it included in distributions. That's generally how things move forward in open source. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Set bash's shell option nullglob by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/13/2012 01:06 PM, Scott Schmit wrote: On Fri, Jul 13, 2012 at 01:56:29PM +0200, Roman Rakus wrote: Hi, I have a question about nullglob bash's shell option. I want to hear opinions. The behavior is nicely described in bash reference manual [1] By default, the nullglob is turned off. And it tends people to use bad habits in shell scripting. In my POV the nullglob could be turned on by default. However, i would like to hear opinions from others. It is possible it can break many scripts even in rpm's scriptlets, but as I already said, it's because bad habits. So the main gain will be the people will learn how is the globbing in bash and in the whole environment working. So ls *.foo should list the entire directory if no files match *.foo? It's a bad habit for me to expect ls *.foo to return nothing in this case? You're going to need to convince me. I wouldn't back this change either but that's not the behaviour of nullglob. If nothing matches the glob the word remains unchanged (i.e. *.foo - *.foo): $ ls *.foo ls: cannot access *.foo: No such file or directory $ echo *.foo *.foo Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAFTIACgkQ6YSQoMYUY956BgCgicpLdJr4nM7NBwYOSJS9kQVe 8qoAoJKEtqaWJ0SAbT2UXK7URkSaxXV+ =H6xC -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Set bash's shell option nullglob by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/13/2012 01:31 PM, Bryn M. Reeves wrote: I wouldn't back this change either but that's not the behaviour of nullglob. If nothing matches the glob the word remains unchanged (i.e. *.foo - *.foo): Eh, nevermind.. not enough coffee. Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAFYMACgkQ6YSQoMYUY94DnACgkaZ3RgDOq98rMsVREgwYMBnG fokAoI9qRfmYOpIv9wzq7u7VMCMCq1zv =MTCR -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2012 02:01 PM, Neal Becker wrote: This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. I think it would be better to ensure the directory is created with the correct permissions. The administrator already has control of the StrictModes setting if they want to relax this restriction. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ggecACgkQ6YSQoMYUY97W+ACfay+Zdd9woIN7OdduzJD9lTb1 kdcAn2PDZRIotmBMeTcjIb1zp5vqsPix =e2zQ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2012 04:02 PM, Kevin Kofler wrote: Neal Becker wrote: Jun 19 09:44:41 nbecker5 sshd[25418]: Authentication refused: bad ownership or modes for directory /home/nbecker Looks like a new change in OpenSSH then, which is IMHO a regression, unless there's a clear security vulnerability being addressed there. OpenSSH has behaved this way as long as I have been using it (I just checked and even sshd_config on a Fedora Core *1* box has the StrictModes option). There's nothing new here at all. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/gmHYACgkQ6YSQoMYUY94UXQCeO0O40DMuJIKZqeCtU2hlKoWL pN0An0QhOTzEncpsFedXeq0OtQJAHUnS =ffof -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: time to fix silly ssh bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2012 02:47 PM, Neal Becker wrote: Bryn M. Reeves wrote: On 06/19/2012 02:01 PM, Neal Becker wrote: This is rediculous. I liked the idea of 775 when it was introduced, since it did solve an annoyance with the old unix groups. But then we should make the default fedora install work by setting the sshd config to allow it to accept this setup. I think it would be better to ensure the directory is created with the correct permissions. The administrator already has control of the StrictModes setting if they want to relax this restriction. The issue is the admin is likely some poor newb installing fedora on his home computer. I argue the reverse - the knowlegable unix hack can change it to make it stricter. Then that's a policy change that should be proposed and reviewed. It's not a bug and there is nothing to fix. The current behaviour is long standing not only in Fedora but in the usptream project that we are packaging. If you'd like to change that policy I'd submit an RFE to the Fedora openssh maintainers but I wouldn't be too surprised if it was rejected. Imho the issue you describe is better dealt with through documentation for newbie admins than by changing a default that would be hazardous for some common configurations. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/gmbwACgkQ6YSQoMYUY97fcwCgwyNUXnkcfYVHnt9v+l/H9sQA O0YAnj6uxrJb0bBqrSzgkHyzz7+CYRYA =hSci -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/01/2012 06:53 PM, Kevin Kofler wrote: Jon Ciesla wrote: For all available firmware vendors and models? For the ones that end users are actually likely to have, which aren't that many. There are much fewer BIOS vendors than hardware vendors. That unfortunately does not translate to fewer BIOS variations. I had a case in the last three months of a system from a major OEM that did not follow any of the common conventions for their desktop systems for accessing the configuration menu during POST. This is particularly common with all those dinky/funky/cute small form factor home and media PCs; they just seem to toss in whatever firmware was lying around the factory floor that day and hope for the best. ;) This is the reality that Peter is talking about when he describes the difficulty of documenting this sufficiently well. Considering the whole of the interwebs can't manage to document how to enter the configuration menu for all systems I'd say he's got a point. I'd also guess that a disproportionate number of owners of these systems are in the POST my what to the who? camp. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/PHh0ACgkQ6YSQoMYUY97AcwCglOl47UpcwiNhWUY5o4mPKpcP UVEAoJwUCOueZXUzmcIsRagxq6tlXDOc =KkzP -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 07:21 PM, Gerry Reno wrote: Not yet. But HDD technology is changing rapidly. Just look at hybrid drives, SSD. No reason they could not add this capability. Not really. Both of these have been in development for years and have only started to look mainstream fairly recently. Look at the time that passed between IDEMA standardising advanced (4KiB) sectoring and the time that that took to actually make it to the market (not to mention that most of those parts are running in compatibility mode today). ATA has some existing security extensions to allow a drive to be locked but these prevent any access until a correct password is presented (and don't appear to be that secure against a well resourced attacker). If read-only support was standardised tomorrow it'd still be a number of years before widespread support became available. About the best you could do today would be to use an external drive with a write-protect switch or to wire up the physical WP jumper on the drive to an external switch on the case (I wouldn't flick it while the system is running ;). Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/Ih3wACgkQ6YSQoMYUY96v7ACfUV2nSsW4iAQDwTXXWz75cpMb fN0AoKHV48bethNR/GKaUdNtnfeNMWlL =mZVJ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 08:03 PM, Gregory Maxwell wrote: I wasn't responding to MJG, I was responding to Peter— who said I was wrong in the message where I was stating that a freedom is being lost, and has subsequently spoken more clearly on the position— and Byrn. It seemed to me that they were arguing that the freedom of fedora wasn't being compromised here. My understanding has been refined by further discussion, though I'm still not completely sure if all people actually take the loss of freedom seriously, or if they do but just can't accept the idea that the alternative is actually an option. If you read my posts carefully you might have noticed that I have not actually taken a position on this feature. I was only responding to the tone and content of your message which I still feel was unnecessarily alarmist and not adding anything to the discussion. I am not working on this feature and I'm quite capable of telling my system's firmware to do what I want so there's little practical implication for me. I see the arguments on both sides and I regret that we appear to be between a rock and a hard place here. At the same time I have a lot of trust in the people who are working on this in Fedora and I have faith that the project will try to seek the best compromise between the freedoms we value and the realities of the market and environment we find ourselves in. Invoking the conspiracy card on these discussions and decisions really just takes us further into the mire. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/IlYIACgkQ6YSQoMYUY95jdgCgtG2ZjWfbZ1eFbV7FJLlvvIrQ 6KcAoLY4Vfca42XC7eby578EOpENakaY =1HB5 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 10:42 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 15:07 -0400, Gerry Reno wrote: Yes, all these would currently support what I'm suggesting. Actually, if you're willing to flip a lot of switches, you could probably make your / a raid5 of floppies, but the performance would be suboptimal. -J Ok, now you're just being silly. Behold: http://www.wired.com/gadgetlab/2009/05/five-disk-floppy-raid-4mb-of-blistering-fast-storage/ Hey, you might be joking but I used to demo MD RAID in Red Hat classes using a dinky little 4-port USB1 hub (with a Shadowman logo) and four Red Hat branded USB keys. Worked great :-) Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ImxUACgkQ6YSQoMYUY96GcgCg0Hl2mIPTJRx4wPUujN4fPVex fL8An1E/1Gd6DQwgzC36hXm2HFk6mCbX =xv75 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/01/2012 01:51 PM, Jon Ciesla wrote: Actually, with enough PCI USB port cards, USB hubs, and thumb drives, you could use MD RAID and possibly LVM to make a poor-person's SAN. Hot-swappable drives and all. And with LIO in the kernel you can even export it over fibre channel or FCoE! Happy days! :) Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/IvrEACgkQ6YSQoMYUY94nOACgszBwn4D4EHl3oWakWXx/XOMH RpMAn2RKxav49G3/pnXx3UqK7rmcaFV8 =ndBc -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 02:48 PM, Gregory Maxwell wrote: From Fedora 18 on, Fedora will no longer include the freedom to for a user to create a fork or respin which is the technological equal of the Project's output. Instead, this freedom will be available exclusively from Microsoft for $99 under unspecified conditions. That's a rather un-nuanced take on things and do remember that the discussions are still ongoing. While there are definitely still some concerns around what is proposed if you took the time to read the URL you posted it should be abundantly clear that there are no restrictions placed on users who do not wish to have the secure boot signature checks enforced. Your message reads as alarmist and flame-baiting especially when there are discussions still going on *right now* on Fedora mailing lists, irc channels etc. on this topic. I wish this were a joke. Suggest something better then: this is open source. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/HeH8ACgkQ6YSQoMYUY95KAACff+XtDGIX3sdcEtku0prbeVDP yCIAoJqXSn5tSLQ7jpxI22xwe3oVKHZH =G6gN -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 03:23 PM, Gregory Maxwell wrote: I thought I'd pay him the respect of sleeping on it and giving someone in support of this rather secretive move time to post about it and discuss it, so that people wouldn't be learning about it from my response. I also wrote a simple, factual message. Nothing I said was distorted or untrue. That discussion is happening right now. You're welcome to join in. Under this model there will be two classes of distributor: One which loads easily on systems, and one which requires the additional effort of disabling secure boot or installing user keys. (And ARM will be even more interesting...) It's rather disingenuous to suggest that this is a situation of Fedora's making. This is coming whether we or other distributions like it or not as a consequence of the Windows 8 logo program. It is a fact that on hardware with this mark *all* distributions will need to either disable trusted boot or find a way to distribute keys to their users or to hardware vendors. If you think you have a better scheme then please describe it. You might argue that the cost of installing keys / disabling secure-boot is sufficiently low— but if if it really were, why bother with it for Fedora, why legitimize this kind of signed boot-loader only control by playing along with it. Perhaps to give the users who want to have Fedora cohabit with another OS that uses trusted boot the freedom do do so without turning it off? So perhaps in practice the loss of freedom is small— but at the same time people advocating closed software will rightly point out that very few users can program and fewer still care to actually do so. Adding your own keys or disabling TP does not require programming skills. None the less, I do not believe it is FUD or in any way inaccurate to say that this will mean that Fedora will be losing a freedom it once had— the freedom to make forks at no cost which are technically equal to the projects, ones which are just as compatible and easy to install. It's a matter of degrees. Other posters are pointing out specific problems they perceive and suggesting concrete reasons why they consider them problematic. Starting a new thread that deliberately omits important aspects (such as the user's ability to toss out and replace vendor keys or disable the whole mess) is pretty close to my definition of fear, uncertainty and doubt. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/HgP4ACgkQ6YSQoMYUY97lCwCfZSfVEc4oKiWfZ5c4kE/rVok6 d0cAnRc7Q4IfFkPvurVbq9KqixV9Q4MY =hh7I -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/31/2012 05:16 PM, Gerry Reno wrote: On 05/31/2012 12:13 PM, Miloslav Trma? wrote: On Thu, May 31, 2012 at 6:04 PM, Gerry Reno gr...@verizon.net wrote: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement SecureBoot is not about security. It is about restriction. That is just untrue. SecureBoot can be used to make sure you only run the software you intended to run, which is impossible without SecureBoot (e.g. this cannot be done with a TPM). The idea is solid, the technology is or can be made solid. No. The user is not in control here. Microsoft is in control. Iff the user chooses to run a Microsoft operating system. Since Microsoft are the owners of the copyright to Windows they are free to apply restrictions to the use of that work on customer's systems. Nobody ever guaranteed anyone the freedom to use and modify another's copyrighted material without the owner's consent. If their users do not like it they can opt out by switching to a different OS. It would be very different if the Win8 logo requirements required it to be impossible to disable secure boot or to enrol 3rd party keys but that is not now the case. Try user-modifying a previously approved installation and see if you, the user, can boot it. If it's not Windows just re-sign, enroll your key and boot. Or turn it off. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/HoxYACgkQ6YSQoMYUY94QBQCgzp0+UVW1595t2+8PfRH4pESG Uq0AoNQyyG4v2+2/RoNhVwcGiBiJqKZq =AWDS -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Now that's a strange error message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/15/2012 07:10 PM, Neal Becker wrote: A bit of sloppy cut and paste gave me this insightful result: $ 0.e+00] bash: 0.e+00]: command not found... Failed to search for file: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5ftransaction_5ferror.Code14: Invalid input passed to daemon: char ']' in text! Do you have PackageKit-command-not-found installed? At a guess it's trying to munch on that string and choking on the ']' (which is not very nice). Try disabling it via /etc/profile.d/PackageKit.sh (and starting a new login shell to ensure it's not inherited from your old environment) to make sure it's PK and then file a bug. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ynmcACgkQ6YSQoMYUY954SQCgu4zeSzGS23eFU03ONjNML2aZ LpMAnRbgquhfybNwfh86Z53O0KKvth7m =IRGk -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Now that's a strange error message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/15/2012 07:20 PM, Bryn M. Reeves wrote: Try disabling it via /etc/profile.d/PackageKit.sh (and starting a new login shell to ensure it's not inherited from your old environment) to make sure it's PK and then file a bug. Also exists on f15 (without the DBus goop) and definitely coming from PK: $ rpm -qf /etc/profile.d/PackageKit.sh PackageKit-command-not-found-0.6.17-1.fc15.x86_64 $ 0.e+00] bash: 0.e+00]: command not found... Failed to search for file: Invalid input passed to daemon: char ']' in text! $ unset command_not_found_handle $ 0.e+00] bash: 0.e+00]: command not found $ Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ynxwACgkQ6YSQoMYUY96pJwCgyQouFcy3MTlcfxJ8sHJaBWC9 9TcAnAvom1N6i3hyemiWSdv/A0nMxyqV =Lds1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 TC1 DVD still no btrfs as install option?
On 04/25/2012 06:22 PM, Chris wrote: 2012/4/25 Josef Bacik jo...@toxicpanda.com: That's because Btrfs is way more stable than ext4, [citation needed] https://twitter.com/#!/josefbacik/status/195190540529184768 Is this a joke? Btrfs more stable than ext4??? Not really??? I think the tongue-in-cheek tags in Josef's mail collided with some antitongue-in-cheek tags in the intertubes and were annihilated. ;) Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Graphical Rescue Mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 06:14 PM, Kevin Kofler wrote: Bryn M. Reeves wrote: On 04/04/2012 06:00 PM, Kevin Kofler wrote: What I think would be really helpful would be a menu item (next to the liveinst one) on the live images which does the same magic to autodetect and mount /mnt/sysimage as the rescue disk does, but from within the graphical live CD environment. I've abused a KDE Live CD as a rescue disk more than once because it's a much friendlier rescue environment than the minimalist one on the rescue image, but mounting the sysimage manually is the harder the more complex the partition setup on the HDD is. That's what makes this hard; supporting the default install layout or very simple setups is quite easy. Catering for anything the user cares to throw at it I think becomes tricky fast. But the rescue mode (which is part of Anaconda as far as I know) already has code for that, we already drag Anaconda onto the live CDs for liveinst, so the code is all there and would only have to be called from the right place! Detecting and mounting the file systems is straightforward and that's what anaconda does. I read the request as wanting to also make the live environment chroot into the detected sysimage and start the system up interactively from there. That seems harder but maybe it's doable (since you don't have to worry about packages being available on the CD as you can use what's already in the installed environment). Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk99WDYACgkQ6YSQoMYUY94luACeMTLfc3dGLK8kHjgyn4wOJqhY XugAoML0CSARAztxDoKvIJAzVeB9bznq =gCQ/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Graphical Rescue Mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/2012 01:43 PM, Kevin Kofler wrote: Bryn M. Reeves wrote: Detecting and mounting the file systems is straightforward and that's what anaconda does. I read the request as wanting to also make the live environment chroot into the detected sysimage and start the system up interactively from there. That seems harder but maybe it's doable (since you don't have to worry about packages being available on the CD as you can use what's already in the installed environment). Then you misread it. ;-) Yeah, I was conflating your suggestion with the earlier request to boot a broken but installed environment using the LiveCD. All I want is a button that mounts /mnt/sysimage the same way as the rescue image does (and possibly opens it with xdg-open so the average user can see what's up), so that I can use the graphical tools on the live image (NOT on the installed system, those might not even work due to broken dependencies etc.) to rescue things. Yep, get you now - I think this is wy easier to do and still useful for a wide range of needs. Cheers, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk99mZ0ACgkQ6YSQoMYUY950XACfTsmCml4s3RDq6/+nY3aYc8z9 5gYAoJqm16pHX2NhsyST8hFvDqsq7XXJ =pj9W -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Graphical Rescue Mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 11:38 AM, Mike Manilone wrote: I think if there's a Graphical Rescue Mode (GRM), that would be great and friendly to end-users. I know many users who can't rescue their systems from a shell. The work needs a lot of knowledge about Linux and shell. But a new user can't learn soon or even they never want to learn about them. However, new users often made mistakes. So I thought about a GRM. Just like Windows' one. Isn't that kinda what a LiveCD is? For administrator rescues I generally use the text rescue mode but on occasions where I've wanted a graphical environment on a dead box I've used the LiveCD. My mother's HD blew up recently and until I could get down to sort things out properly I sent her instructions to burn and boot a LiveCD and then hacked around with things to get a recent backup of her home directory content available. Worked pretty good and apart from having to talk her through a few systemctl commands to get sshd up was very simple for all concerned. Maybe it would be an idea to extend livecd-tools to allow a live image to be installed to the hard disk and booted via grub to allow a graphical environment to boot up when the main install is hosed for some reason. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk98KZIACgkQ6YSQoMYUY97TnACfQfqrJUmT4gg8Io+9qNJsPs5V aTkAnjNsElnlqUcPQOxnFmz5U/2u56E3 =vNzt -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Graphical Rescue Mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 12:05 PM, Frank Murphy wrote: On 04/04/12 11:38, Mike Manilone wrote: Hi there, I think if there's a Graphical Rescue Mode (GRM), This can be done with install dvd, troublshoot recsue installed system chmod /mnt/sysimage (iirc) chroot /mnt/sysimage :-) This should work as long as the rescue CD finds all your file systems and mounts them in the right place (inc. bind mounts for /proc, /sys, /dev). If not then setting them by hand isn't a big deal. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk98L88ACgkQ6YSQoMYUY94OogCfXFPPdQ1pcLMqwtLapsPpI5Zz ixUAn27IsKXoUkn6YzvwISpSZLg2gdaN =GPdc -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Graphical Rescue Mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 12:06 PM, Mike Manilone wrote: On Wed, 2012-04-04 at 11:59 +0100, Bryn M. Reeves wrote: Maybe it would be an idea to extend livecd-tools to allow a live image to be installed to the hard disk and booted via grub to allow a graphical environment to boot up when the main install is hosed for some reason. Surely it also works. However, can it integrate to the main release? Then it can be useful. Doing that by hand isn't so hard for simple cases (add some users with the right uid/gid, meddle with some mounts, maybe turn on some services). This is all I've generally needed when doing this kind of thing and it works well. If you're wanting to start a complex environment (say, a server with multiple services running and a non-trivial configuration) then I think that's a much harder problem to solve. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk98MEwACgkQ6YSQoMYUY972iQCfXgP54TbJS2xVJF8/Lb61oZ8/ C6cAoJaH4cCS+cnSqagcKR9kZ1fKcDP3 =ZvHj -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Graphical Rescue Mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 12:13 PM, Mike Manilone wrote: On Wed, 2012-04-04 at 12:05 +0100, Frank Murphy wrote: This can be done with install dvd, troublshoot recsue installed system chmod /mnt/sysimage (iirc) startx If there's a grub entry will be more user-friendly. However, if the DVD broke, what can I do? USB storage device? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk98MGAACgkQ6YSQoMYUY95jewCgzII0p/zvNyNuPB3B9+xWPxuc eKkAoJHRgHnz1dBbQ75hmythCI/4Tjj7 =hLjf -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Graphical Rescue Mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2012 06:00 PM, Kevin Kofler wrote: Bryn M. Reeves wrote: This should work as long as the rescue CD finds all your file systems and mounts them in the right place (inc. bind mounts for /proc, /sys, /dev). If not then setting them by hand isn't a big deal. It's still a text-only environment. Not if you get all the chroot stuff right and then run the subsequent startx (that I neatly chopped out when trimming my reply). I so rarely use it this way though that I am not aware if there are any problems to doing it this way these days (last time I did stuff like this was probably while teaching a class based on 2.4 kernel distros..). What I think would be really helpful would be a menu item (next to the liveinst one) on the live images which does the same magic to autodetect and mount /mnt/sysimage as the rescue disk does, but from within the graphical live CD environment. I've abused a KDE Live CD as a rescue disk more than once because it's a much friendlier rescue environment than the minimalist one on the rescue image, but mounting the sysimage manually is the harder the more complex the partition setup on the HDD is. That's what makes this hard; supporting the default install layout or very simple setups is quite easy. Catering for anything the user cares to throw at it I think becomes tricky fast. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk98fxcACgkQ6YSQoMYUY94BugCghimRALNDg344lI+gWAJh21hY vhEAn2NlfK7+6laifaOGuuGkDBRYfWgz =W89h -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 01:15 PM, Joel Rees wrote: On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves b...@redhat.com wrote: You're allowing the local sandbox user to connect to the local X server so any process running in one of your sandboxes can start a connection to X and start looking for vulnerabilities to exploit. Of which X11 still has its share, we are told. Humor me. Does running firefox this way, as a different user on the same machine, increase risks, as compared to running firefox as the user you are logged in as? If so, how? If the reason you are running the separate browser is to visit sites that you do not trust sufficiently to visit from your main user session then yes because the browser (and in turn X) is now exposed to those sites. If your choice is or do nothing and run them in the normal session then of course there is no difference. Due to the elevated privilege with which X runs this could include privilege escalations. Okay, so why doesn't Fedora drop privileges on Xorg like a certain BSD does? I'm no X expert but historically the X server needed root privileges to use vm86 mode to interact with the video BIOS and to access the IO ports for the card so KMS for all drivers at least is required to be able to support this. OpenBSD modifies the Xorg source to allow privilege separation and this work has not made its way upstream (which is a problem for Fedora to include it). There are also legitimate questions about how useful all of this is; although OpenBSD provides their aperture driver to minimize the address space the X server can access Theo de Raadt has said this is just the best we can do. OpenBSD also provides a vesafb driver that permits an unprivileged X server with no aperture driver but acceleration is not supported and performance suffers as a consequence. Well, sure. That's going to happen when you run a server as root. But does it open holes to run the application accessing X as a different user? ergo, holes that wouldn't be open when running the same application as the user you logged in as? Yes; if you don't trust those applications or the data (sites) they operate on then you have a possible avenue for attacks. This is the point of sandbox -X. This blog could help me figure out SELinux's ACL tools, which, if I continue to use Fedora, it looks like I'll have to learn to use. In self-defense, if for no other reason. SELinux doesn't provide ACLs (Linux ACLs are primarily a file system feature that's independent of other security frameworks in use). I notice that he is using mount-over tricks to augment the protections. Fancy or funky? I'll have to re-read that when I have time. Just sane. Linux has supported per-process mount namespaces for a very long time. They provide far stronger isolation than other methods. They're also worth getting to know as they are useful for many other tasks too. You know, one of the problems with ACLs (and capabilities) is getting them set up right. And you know how it ends up? Well, as you say, and as Walsh acknowledges, Use it/don't use it - it's up to you. I've used SELinux sandboxes and I find them very easy to use and considerably less maintenance effort than roll-your-own. YMMV of course but I prefer not to invent my own solutions to security problems when there are off the shelf answers that were developed by people who work on this stuff every day. There's also a tonne of good documentation for SELinux these days from basic administration to troubleshooting and advanced policy development: http://fedoraproject.org/wiki/SELinux I've been trying to avoid what I'm sure amounts to blasphemy in the eyes of some on these lists, but I am not particularly fond of SELinux. Way too many convolutions to hide bugs in. If X11 must be assumed to have bugs, so much more, the more recent and It's been around for well over a decade now and is pretty mature. Bugs still happen but I think they're no more troublesome than bugs in any other complex subsystem these days. The SELinux folks I know are also very responsive and helpful when dealing with user problems. more complicated SELinux, especially in the patterns by which the tools to set policy are run. Not sure which X sources you've looked at but this certainly isn't my impression of the two projects. The xorg-x11 sources weigh in at over 500,000 loc just for the server. Adding libX11 and a few other libraries quickly takes you over 750k. Adding up security/selinux from the kernel sources along with policycoreutils and libselinux you come to about 68,000 (and that's including all the pcu python stuff - without that you can take another 20,000 off). Even if you include the reference policy specs it's less than a quarter million lines. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Re: users, private groups, and The Unix Way (was, Re: Is it me or is it sudo?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2012 04:56 PM, Joel Rees wrote: Good point. I don't visit those sites, and it's important for me to mention that. No p0rn, period, and many of the moral reasons are in There are a lot of perfectly family-friendly websites whose administrators I do not trust as far as I could throw them (even if I knew where they were). in the subuser's directory tree. Again not perfect, but a bit of a higher wall than a speed bump. If the payload targets an X vulnerability there is no difference. License issues? Getting the source should be now problem. Upstream first - Fedora goes out of its way to get new features into the distribution by getting them into the projects it packages upstream (often by doing the work upstream). There are occasional exceptions but it's very unusual for Fedora to take a large set of changes from another downstream packager before they get merged. address space the X server can access Theo de Raadt has said this is just the best we can do. What he means by that is a bit different from what you would mean by that. Thank you for enlightening as to what I meant (although what you assume I mean by that may not be the same as what I actually meant when I wrote it). to defeat, enough so that social engineering or bruteforcing tend to be preferred. Unless you have someone specifically targeting your network, in which case, you really have to restrict what you do on That's not the case at all. It's just a more constrained interface to the same thing (and Linux is fairly restrictive about that these days too). A smaller attack surface doesn't mean that you need targeted attacks; almost certainly if someone discovered an exploitable flaw in this it could be developed into an easily deployed local exploit just like any other. What I understood from Theo's statement is that while it tightens some avenues for exploit development the basic model of exposing hardware to a userspace process (privileged or not) is broken. Not everybody agrees but there is a lack of a usable alternative right now. He also goes on to state that X: violates all the security models you will hear of in a university class. due to the exposure of the device registers, memory space and I/O ports to userspace (drivers in userspace model) and that the X developers are a bunch of shameless vendor-loving lapdogs who sure are taking their time at solving this 10 year old problem. I am sure such words would motivate me to help him if I worked on X. Yeah, it's going to be relatively slow. But it would be nice to have that as an option. (Most of what I do would not suffer significantly.) There are vesa drivers in Fedora. I have no idea how difficult it would be to coax them into running unprivileged but if it interests you you might want to look into it. Kind of like seatbelts. You have to regularly ask yourself if they encourage dangerous driving, and check your habits if you're getting sloppy. The evidence base disagrees here. Multiple studies find large declines in casualty figures following introduction of mandatory seatbelt laws: http://jech.highwire.org/content/43/3/218.full.pdf http://tinyurl.com/bu6ymdn [jstor] Which would be nice if I trusted ACLs. But you trust the kernel, Xorg and Firefox which are considerably larger and more complex beasts? Ok... I thought those policies were just a way to compile those lousy ACLs so you wouldn't be spending more time setting the ACLs than doing actual work. Not quite: SELinux provides a framework for defining access control policies based on users, roles and types (aka domains). The policy defines what actions a given user/role/type combination is permitted to carry out. Daemons and other confined processes are placed in a specific domain to limit their access to system resources according to the policy: http://en.wikipedia.org/wiki/Security-Enhanced_Linux You can use this to implement RBAC, MCS, MLS etc. SELinux contexts are stored along side files in the file system as extended attributes (xattrs) - i.e. it's label-based rather than path-based security. Xattrs are also used for ACLs in many file systems so that may be where the confusion arises. ACLs usually refer to access control lists - most often file system ACLs although there are many other uses of the term e.g. BIND DNS ACLs or Microsoft Windows fs ACLs mapped through Samba/CIFS. An ACL is just a list of identities and the level of access they are permitted. Fs ACLs are available with any modern Linux file system and operate independently from any LSM security framework in use. Per-process could be an interesting, might be able to combine that with other things I do. Check out pam_namespace which does per-session namespaces (and probably more now, it's been a while). There's a post from Russell Coker discussing it here: http://etbe.coker.com.au/2008/12/13/per-process-namespaces-pam-namespace/ Well, if I were inventing,
Re: Question about commiting the sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2012 02:33 PM, Jan Synacek wrote: On 03/16/12 at 11:16am, Sergio Belkin wrote: Perhaps and stupid question: After upload new-sources to repo, it outputs: Uploaded and added to .gitignore: Source upload succeeded. Don't forget to commit the sources file I don't understand! By default it add sources files to .gitignore and then it asks for commit them? Is it something that I misunderstood? It just tells you not to forget to commit the file named 'sources'. The file changes when you execute new-sources and should be commited, because it contains an md5sum of the source tarball. The message is somewhat misleading, because the 'sources' file gets staged automatically after new-sources, so if you do fedpkg commit, it gets commited anyway. It's also a bit unclear in that the thing that was added to .gitignore is the tarball file name (you don't want to check it into the VCS - that's what the lookaside is for). Maybe it would be more explicit to output a line like: Uploaded and added fooble-1.2.3-rc3-git1.tar.gz to .gitignore: Should be a quick simple patch. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9jUWsACgkQ6YSQoMYUY95kswCgvJTVh/o5YSeY/Bv6sfOSKLwC 7BAAnA3N+i0zu9rL3BzY0D501OfTk5nL =lrjK -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundled part of code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/17/2012 04:01 PM, Jon Ciesla wrote: No, it really should use the system version. If it's not in Fedora, submit it as a review for a new package. -J If I read correctly there is no system version since the code discussed is not a library: it's just a blob of source borrowed from another project, transplanted into another tree (with a different license..) and compiled/linked into the app. Pavel, right? Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8VnnkACgkQ6YSQoMYUY950kwCg3F3pFIdUaBVQ/1/AMgosyrO/ puwAoKxGYXUGGZ8ffPxtAb9Fp7SDJQbg =jv6R -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Zif and SOS projects on Fedora Upstream
On 10/24/2011 04:05 AM, Misha Shnurapet wrote: There is a project named SOS in Fedora collection on Transifex. I'd like to know if there is anyone maintaining it, because it seems like it needs to be translated, but there is no maintainer assigned in Tx and no translation team creation request has been fulfilled in 7 months. The latest change to code in Github is 6 months old. We tried to contact Adam Stokes mentioned in the source readme on Github, but no reply yet. Any help with getting response is much appreciated. Hi Misha, I'm the maintainer for sos now (took over from Adam last year). We migrated from SVN to git back at the start of the year and also submitted an infrastructure ticket to get the transifex details updated. It looks like that got stuck somewhere - I'll check to see what's going on. Also, upstream is using a github repository for development for the last couple of months. You can find the repositories here: https://github.com/organizations/sosreport Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On 08/12/2011 04:40 PM, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 08:27:13AM -0700, Toshio Kuratomi wrote: Rightly or wrongly, upstream libfoo-1.0 has some additional utilities that access the PrivateData. Because the utilities are built from the libfoo source, they can include the fooprivate.h header file and do this. When libfoo goes to 1.0.1, upstream changes the definition of PrivateData and updates the utilities to work with the new datastructure. Since the public ABI stayed the same, the SONAME doesn't change and external programs compiled against libfoo-1.0 continue to work but the utilities built as a subpackage would be broken without stricter versioning. Upstream can change the ABI as much as they want without bumping the SONAME providing that the old interfaces are also present. It's entirely possible to end up with a situation where external binaries built against 1.0.1 won't run on 1.0.0 - the problem isn't limited to subpackages. I think Toshio is talking about the case where the subpackage executables are using things that are explicitly outside of any defined ABI (since they are compiled from the same source tree and have access to non-public headers and types defined within them). In his example PrivateData was never part of the interface that external code using -devel sees. Third party code built against -devel and depending only on the SONAME is fine in this situation as it sticks to the published ABI. In-tree code that plays with non-ABI symbols will break and so may need a stricter dep. It's easy to argue that this is a misuse of the interface or that the interface is inadequate/broken but I'm sure there are packages out there with this problem. Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/27/2011 03:14 PM, Bernd Stramm wrote: On Wed, 27 Jul 2011 15:54:09 +0200 Lennart Poettering mzerq...@0pointer.de wrote: If you don't hide ~/.local and ~/.config then users who are less savvy than us might wonder what thzat stuff is and delete it and nothing will stop them and then all their configuration is lost. Hiding configuration is one thing, hiding executables is another. Hiding executables is a security risk, and should not be done just because a single person asked for it in a BZ. There are already quite a few things that may place executables under . prefixed paths in home. Java web start (javaws) for instance will install an entire jre under .java/deployment/cache, wine has for many years installed Windows executables (that can be executed by the system) under .wine, browser plugins may be installed to .mozilla/plugins and are just as capable of performing evil actions as an executable (e.g. drop a malicious plugin that hijacks some common MIME types, do your $evil and then wrap the intended plugin). There are various other examples - on an older release I find 171 such files under ~/: $ find $(l. | egrep -v '\.$|\.\.$') -type f -perm /111 | wc -l 171 Some of these aren't actually binaries/scripts - e.g. .desktop files and others just appear to have wrong mode on creation but it's still clear that this is nothing new. I think the security aspects of this change are being overstated in this thread. If something has already obtained the ability to create executable files under a user's home directory then your men are already dead; The sophistication needed to exploit it might vary a little but that's not something that gives me great comfort. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/28/2011 12:54 PM, Bernd Stramm wrote: On Thu, 28 Jul 2011 11:24:48 +0100 Bryn M. Reeves b...@redhat.com wrote: There are already quite a few things that may place executables under . prefixed paths in home. Java web start (javaws) for instance will install an entire jre under .java/deployment/cache, wine has for many years installed Windows executables (that can be executed by the system) under .wine, browser plugins may be installed to .mozilla/plugins and are just as capable of performing evil actions as an executable (e.g. drop a malicious plugin that hijacks some common MIME types, do your $evil and then wrap the intended plugin). There are various other examples - on an older release I find 171 such files under ~/: $ find $(l. | egrep -v '\.$|\.\.$') -type f -perm /111 | wc -l 171 This is no excuse to add to a bad habit. I'm not using it as an excuse for anything but I do think it is evidence that the security implications being bandied around in this thread are rather overblown; as others have said an attacker that can write to these locations is /already/ a problem. Using ~/.local (or any other path in home) doesn't make that any better or worse. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/28/2011 01:41 PM, Genes MailLists wrote: On 07/28/2011 07:53 AM, Bryn M. Reeves wrote: On 07/28/2011 12:46 PM, Genes MailLists wrote: This is a good point. Especially when you start on a 64 bit box and login to a 32 bit (or other arch) - bin now makes now sense at all. You need arch specific bins (bin, bin64 etc). Currently Fedora only separates out the /lib* directories in multilib installations - you'll find a mix of 32 and 64 bit binaries in the system binary paths on these systems. which is fine for a 'system' which is 64 bit and may support 32 bit as well - its not fine for a 'user' who logs in to a 32 bit machine from a 64 bit machine and now his binaries wont work. Separating bin paths like this would not solve the problem; anything that's only present in one path or the other would still fail in the scenario you suggest. You could equally install foo/foo64 or vice versa into the same directory. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/28/2011 01:22 PM, Bernd Stramm wrote: On Thu, 28 Jul 2011 13:00:28 +0100 Bryn M. Reeves b...@redhat.com wrote: It is nevertheless an *added* avenue to do some phishing. And for what benefit? No, it's not; at the very most it's making something very slightly less noticeable but even that is a weak and flawed argument. If your security relies on spotting that a malicious user has placed a rogue binary in ~/bin you're already hosed. Adding a hidden directory to $PATH will cause people do filter it out from their $PATH. This leads to more messy use environments, not to cleaner ones as is the original purpose of this whole thing. No, hidden directories should not be in $PATH. If somebody put that in their standard, those folks should change their standard. Standards can define things that are wrong, and this is one such case. I'm not especially attached to ~/.local/bin being in PATH (although I do happen to think the approach used by python for --user installations is an elegant solution). What I disagree with is the use of bogus security handwaving to support an argument against it. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/28/2011 03:50 PM, Braden McDaniel wrote: My understanding of the history of /usr/local's nomenclature is that it was intended to be local to the machine (and thus not NFS mounted). I always understood it to be site local rather than machine local - the FHS states that it may be used for programs and data shareable amongst a group of hosts (but again, NFS mounted /usr, /usr/local or even separate (but local) /usr has some problems today). Your point applies just as well to /usr; but I think the intent was for NFS-mounted /usr to accommodate a single point of installation in homogeneous environments; supporting heterogeneous environments just wasn't the point. My impression is that NFS-mounted /usr is pretty uncommon these days--and perhaps unheard-of using Linux. It's not unheard of historically but see for e.g.: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken NFS-mounted $HOME, however, continues to be relatively common and certainly warrants consideration. Agreed. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/27/2011 11:43 AM, Ric Wheeler wrote: On 07/27/2011 01:23 AM, Adam Williamson wrote: On Tue, 2011-07-26 at 07:07 -0400, Ric Wheeler wrote: We track autofs issues for fedora, upstream and RHEL and seems to work well in the field. What specifically does systemd do that autofs does not do without it? I don't know if there is anything, but it's neat to get something like this 'free' with systemd, without having to add any other package. It is fine for really simple use cases, but the complexity of what autofs does for large deployments is huge I don't know enough about how systemd does the automount support, it might be leveraging autofs? It appears to use the kernel autofs support but replaces the userspace daemon (and replaces the traditional automounter map file format with system.automount unit files). I can appreciate a benefit for personal systems from systemd managing network file system mounts since it's in a position to know when the network is up (this has been a problem with /etc/fstab, NFS/CIFS and NetworkManger for some time) but I'm not sure that large deployments with existing autofs infrastructures will be so keen to make the switch. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: thanks for F15 mdadm systemd unit
On 07/20/2011 11:05 PM, Reindl Harald wrote: hopefully systemd will aslo live for 40 years as sysvinit did or the next replacement will be finished BEFORE release including the correspondending parts of the distribution Just to be clear as this has been mentioned several times in recent threads: System V style initialisation is _not_ 40 years old. SysV was only released in 1983 (and even after that time there were alternatives - the BSDs never adopted this approach to system initialisation). Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On 07/14/2011 05:26 PM, JB wrote: Now just a loud thinking ... Have you thought about first preparing a CD (even a live CD) with BTRFS and some extra preinstalled software like VirtualBox etc just for testing ? What, you mean like the live and non-live Fedora ISOs that have had btrfs support available as an option during install since Fedora 11 (mid 2009ish)? Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On 07/14/2011 05:48 PM, JB wrote: Good. Perhaps a weekly snapshot CD, with the latest BTRFS and related utils, so that the testing would be more up-to-date and meaningful. JB http://alt.fedoraproject.org/pub/alt/nightly-composes/ Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns
On 06/02/2011 08:28 PM, Richard W.M. Jones wrote: Maybe I'm not understanding your question correctly, but a filesystem is more general than LVM. You can create directories corresponding to your current VGs and files for your LVs, with the advantage that you can nest directories which you can't do with LVM VGs. If you mean nesting in the sense that an LVM2 LV is used as a PV then the tools support this just fine: # lvcreate -n nested_pv1_lv -L5G bmr_vg1 Logical volume nested_pv1_lv created # pvcreate /dev/bmr_vg1/nested_pv1_lv Physical volume /dev/bmr_vg1/nested_pv1_lv successfully created # vgcreate bmr_nested_vg0 /dev/bmr_vg1/nested_pv1_lv Volume group bmr_nested_vg0 successfully created # lvcreate -n nested_pv2_lv -L5G bmr_nested_vg0 Insufficient free extents (1279) in volume group bmr_nested_vg0: 1280 required # lvcreate -n nested_pv2_lv -l 1279 bmr_nested_vg0 Logical volume nested_pv2_lv created # pvcreate /dev/bmr_nested_vg0/nested_pv2_lv Physical volume /dev/bmr_nested_vg0/nested_pv2_lv successfully created # vgcreate bmr_nested_vg1 /dev/bmr_nested_vg0/nested_pv2_lv Volume group bmr_nested_vg1 successfully created # lvcreate -n l0 -l 1278 bmr_nested_vg1 Logical volume l0 created The 1-extent-per-nesting-level size decrement is to allow for the MDA allocated on each PV. The pvcreates are also strictly speaking unnecessary on recent tool versions since a vgcreate will now label a new device automatically but I'm old-fashioned ;-) You can view the device nesting via dmsetup: # dmsetup ls --tree bmr_nested_vg1-l0 [...] bmr_nested_vg1-l0 (253:10) └─bmr_nested_vg0-nested_pv2_lv (253:9) └─bmr_vg1-nested_pv1_lv (253:8) └─ (9:1) [...] # vgs VG #PV #LV #SN Attr VSize VFree bmr_nested_vg0 1 1 0 wz--n- 5.00g 0 bmr_nested_vg1 1 1 0 wz--n- 4.99g 0 bmr_vg0 1 4 0 wz--n- 222.82g 25.68g bmr_vg1 1 3 0 wz--n- 19.53g 6.62g If things aren't activating properly on boot/reboot then it's likely an initscripts limitation or bug. Udev based activation should simplify that but you can also work around it depending on your distro via e.g. rc.local. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: artificial limit, 1024 processes by user
On 05/14/2011 08:35 PM, Henrik Nordström wrote:
lör 2011-05-14 klockan 19:33 +0200 skrev Xose Vazquez Perez:
default is 24010, but it was reduced to 1024 by
user(included root) in: /etc/security/limits.d/90-nproc.conf
to prevent accidental fork bombs(see rhbz #432903).
Is it still worth it? The kernel brings oom_kill.
Yes it's needed.
Also it's trivial to tune when needed, even on an per process basis,
just use ulimit -u to set it to whatever you want (within the hard
limits of the box)
Agreed. Just disable it and run something like the old _(){ __ };_* tricks
if anyone needs convincing (and to see the fun that oom kills can bring try
something like echo {0..100} on a box with no memory ulimits).
Cheers,
Bryn.
* yes this may well break stuff.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Interlinux waiting list
On 05/10/2011 03:05 AM, Adam Williamson wrote: On Mon, 2011-05-09 at 21:14 -0300, Sergio Belkin wrote: Sorry... Did I miss something? I'd imagine someone signed an interlinux address up to the list, and that was an automated response. Right - that was my assumption too. I met the owner of the domain through a past job at Red Hat and I suspect this is an accidental (though annoying!) mis-configuration caused by someone registering the fedora list address. I'm trying to get hold of him to say please make it stop!. ;) Please don't reply to the domain addresses as this appears to trigger more auto-responses. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: illegal instruction - create compile variants ?
On 05/01/2011 11:46 AM, Reindl Harald wrote: Am 01.05.2011 09:56, schrieb David Timms: Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ? Can that even be done (reliably)? ffmpeg has since years a option --enable-runtime-cpudetect what makes the binary a little larger but let it run on all CPUs with good performance so yes, it is possible And libmpeg2 and many, many other especially multimedia libraries that can get a large benefit from the SIMD and other extensions in later CPUs. This really should be done at runtime and either a jump table consulted, or code patched in/out by some means (if the expense of pointer lookups on each op is excessive). I recently became aware of rakarrack and would very much like to use it so I might take a peek at the source to get an idea of the work involved as this is an area of interest of mine (hobby thing though - I can't promise to have lots of time to spend on it!). Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 04/14/2011 04:38 PM, Michał Piotrowski wrote: 2011/4/14 Jason D. Clinton m...@jasonclinton.com: 2011/4/14 Bruno Wolff III br...@wolff.to On Thu, Apr 14, 2011 at 16:53:00 +0200, Michał Piotrowski mkkp...@gmail.com wrote: Fixed a rare condition that could cause the drive to reset and clear the data I begin to wonder if it was the right decision to change main drive to SSD :) Maybe it's time to start using data=journal If you want to read some scary stuff some SSDs do take a look at the following comment from LWN: http://lwn.net/Articles/437467/ All the compacting firmwares on all SSD's do this. I hope that it works this way only on NTFS and do not attempt to free unused Ext4 space :) Dan Berrangé and I were just wondering how it knows it's NTFS; what happens for e.g. if you put an image of an NTFS volume inside an ext4 volume on one of these things? Kinda brings back memories of reiserfsck fun. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ext4 + barriers=1 + ssd + power loss while commiting to a git repo = broken repo?
On 04/14/2011 04:38 PM, Adam Williamson wrote: On Thu, 2011-04-14 at 09:15 +0200, Michał Piotrowski wrote: Hi, I experienced a small loss of power during commiting to a git repo. I can't resist...how does a 'small' loss of power differ from a 'large' loss of power? :) Haha only-serious but in my (probably outdated dead-tree :) book: Small loss of power: Enough to get the smoothing caps draining and kick up some wobble on the rails (might make your DRAMs go nuts). Aka a brownout. Large loss of power: Fetch the candles! (a blackout!). ;) Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's this /run directory doing on my system and where does it come from?
On 03/30/2011 01:11 PM, Ralf Corsepius wrote: On 03/30/2011 02:10 PM, Michał Piotrowski wrote: 2011/3/30 Ralf Corsepiusrc040...@freenet.de: On 03/30/2011 01:54 PM, Lennart Poettering wrote: Heya, I just uploaded a new version of systemd into F15, which establishes a directory /run in the root directory. Most likely you'll sooner or later stumble over it, so here's an explanation what this is and why this is. It's a fairly minor technical change, It's a massive FHS violation FHS has 7 years, must be updated. = release blocker. Flame! :D No, it's a no-go/no-way in most verbose form. If strict FHS compliance was a release criteria it's hard to see how we'd have made it to F15 in the first place. I also don't think you can really justify the massive qualifier in your assertion. The actual text of the (7 year old) FHS has this to say: Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package. Rationale There are several reasons why creating a new subdirectory of the root filesystem is prohibited: • It demands space on a root partition which the system administrator may want kept small and simple for either performance or security reasons. • It evades whatever discipline the system administrator may have set up for distributing standard file hierarchies across mountable volumes. Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability. I'll agree that the standard's wording isn't as clear as it might be (don't you just love 'em?) but the last paragraph certainly seems to allow distributions to add subdirectories to the root directory with extremely careful consideration of the consequences. I find it interesting that you consider a breach of the root directory pollution rule sufficiently serious to be a release blocker and yet you have apparently remained silent as all the abuses of the /dev directory that Lennart pointed out were merged in previous releases. Why is that those FHS violations are OK but adding a directory to / (in an obvious effort to address one of the shortcomings of the existing standard) is the end of the world as we know it? No standard is or even should be carved in stone for all eternity. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's this /run directory doing on my system and where does it come from?
On 03/30/2011 02:08 PM, Ralf Corsepius wrote: On 03/30/2011 02:30 PM, Lennart Poettering wrote: On Wed, 30.03.11 18:04, Rahul Sundaram (methe...@gmail.com) wrote: Also, can somebody point me to the place where the FHS would say no other directories below / are allowed? I can't find that. And hence this change is perfectly FHS compliant. It's in the preface of the root file system section: http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM cite Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package. /cite Fedora is a distribution, not an application. You neatly elided the following paragraph that explicitly grants distributions the right to do this with careful consideration. Well done. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: new raid1 read balance working, please test it! kernel 2.6.37 based
On 02/08/2011 02:22 AM, Roberto Spadim wrote: hi guys, i made some changes to md raid1 software, could fedora test it? for me it work very nice =) the raid1 new code is based in kernel 2.6.37 here is the new and old code: www.spadim.com.br/raid1 just read_balance changed (4 modes: near_head(today) round_robin(counter per mirror) stripe (like raid0, with shift for make stripe less or more intensive), time based (depending on head positioning time and read size it calculate the fasted mirror, some new improvement must be done but it works, improvements= get io queue of each mirror and many a time estimation of queue time, with it get more close best disk) it´s open source please help me testing it, neil at raid kernel must some benchmarks to put it inside kernel source for mixed speed mirrors time based is good, for ssd only round_Robin is good (per mirror count, put 230 for 230mb/s, 150 for mb/s or multiples to make a good round robin) for disks and/or ssd mixed or not, stripe is good for disks only near head is good Hi Roberto, You might find it's better to discuss this on the linux-raid mailing list hosted at kernel.org: http://vger.kernel.org/vger-lists.html#linux-raid The list is dedicated to discussion of RAID technologies and their use with Linux, including the kernel MD subsystem. You might also find it easier to get review and testing of your changes if you distribute them as unified diff files instead of .old.c/.new.c files. Diffs or patches are the standard format for distributing and reviewing changes to source code and by using that format you make it more likely that others will test, read and comment on your code. It's also a good habit to get into to break your changes up into a series of smaller logically related changes. This makes reviewing changes and spotting bugs or errors easier and also makes it easier to get changes accepted (since hard-to-review stuff is less likely to make it in). There are some basic guidelines and answers to common questions here: http://www.kernel.org/pub/linux/docs/lkml/#s1 There's lots of documentation that goes into more detail on the process and recommended if you search around. I turned your changes into a patch that follows the usual conventions here: http://fpaste.org/Uqqy/ It's still a big patch but much easier to review in this format. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mounting an encrypted volume presents the volume to all users on a machine
On 10/26/2010 10:39 PM, Bruno Wolff III wrote: On Tue, Oct 26, 2010 at 14:07:53 -0700, Jesse Keating jkeat...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- That's only if you give root the right to disable or load new selinux policy. And the policy is tight enough. You need to not allow root shells or most processes the ability to read the keys out of memory or to write memory that will change how things work. I don't think targeted policy is locked down enough to stop that even if you don't allow root to disble selinux. Seriously, there are machines on the public Internet with a published root account. You're welcome to log in and try to do anything with them. Yeah, I know about one guy that offers a root password if you ask. I am not sure what policy he is running on that machine. It's Russell Coker, access details are available here: http://www.coker.com.au/selinux/play.html However the pages haven't been updated in a while and the service seems to be down right now. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -static packages
On 09/15/2010 05:06 PM, Robert Spanton wrote: Hi, I've recently had to link a fair amount of my work statically so that it'll run on a cluster of RHEL machines. Unfortunately, I am just a user of these machines, and so I don't have the power to get them to run Fedora or even to get the admins to install RHEL packages in a timely manner. Building statically also helps me to eliminate as many of the inevitable fractional differences between cluster nodes as possible, to achieve reproducible results from simulation runs. However, only a few packages in Fedora provide -static variants. This has meant that I've had to locally build these, which is obviously not desirable from a maintenance perspective. So, would be acceptable to register requests for -static package variants as tickets on bugzilla? Or is there a better way to try to encourage people to generate these packages? You might find the Fedora packaging guidelines for packaging static libraries helps explain the rationale a bit more: http://tinyurl.com/kz4rp [fedoraproject.org] There have also been several discussions of this on the fedora lists over the years, e.g.: http://www.spinics.net/lists/fedora-devel/msg48361.html Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/24/2010 09:39 PM, Matt McCutchen wrote: On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: Why is the systemd executable in /bin instead of /sbin? Without looking too closely I believe systemd eventually seeks to replace things like gnome-session daemon. It has session management in mind as well as system. Still belongs in /sbin, unless it's meant to actually be executed directly by end-users. No. If that were the criterion, update-mime-database would belong in /sbin . The FHS puts it like this: (a) /bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts. (b) /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. So if the intent is that systemd will eventually be invoked (indirectly by some script/daemon) by users this seems justified by (a). On the other hand the page has this to say on init: The following files, or symbolic links to files, must be in /sbin if the corresponding subsystem is installed: ... init It's arguable though whether this refers to SysV's init or is intended to be more general. http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxNVfQACgkQ6YSQoMYUY95UngCgxoS3//7yzpXZriKSCZMFnun+ 1qoAn107myHo05jderCykLfKsSmqYAmS =iYOx -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On Wed, 2010-03-10 at 19:11 -0800, John Reiser wrote: MultiGHz, Multicore CPUs consume magnitudes more power than HDs. Not always. A typical 3.5 harddrive consumes about (max): 0.65A * 5V = 3.25W 0.50A * 12V = 6.00W which totals 9.25 Watts, and less when not transferring data. I am composing this message on a system with a 2.5GHz, two-core processor that consumes 45 Watts maximum, and less when idle. So in this case the ratio is closer to 5:1, not 10:1. That doesn't compare to figures that I have seen - a lot of 7200rpm hard disks will draw up to a couple of amps on the 12v line (at least, during startup) giving you peak power consumption in the 20-30W range. The lastest data sheets I can find for Seagate's Baracuda 7200 drives for e.g. quote a maximum draw of 2.8A (33.6W). Admittedly that's a peak value and not an average but so is the 45W processor figure; I think claiming that modern CPUs consume magnitues more power than modern hard disks is not justifiable. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Not prepared for 4096 byte sector hard drives?
On 02/14/2010 04:59 PM, Neal Becker wrote: Any truth here? http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096- Byte_Sector_Hard_Drives One-line-summary: googling common search terms for Linux help may lead you to some out-of-date HOWTOs. This passes as news these days? :-O Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: best practice for packing programs that use strlcpy()?
On Thu, 2010-01-28 at 23:38 -0800, Eric Smith wrote: Tom spot Callaway wrote: You could probably package up libbsd for inclusion: http://libbsd.freedesktop.org/wiki/ That's exactly the kind of thing I was hoping to find. I've submitted a package for review: https://bugzilla.redhat.com/show_bug.cgi?id=559856 Be aware also that despite rumors to the contrary it's just as easy to misuse and abuse srtl* and friends as the other string handling routines. Code using them should be subject to the same security review scrutiny as code using other string mungling interfaces. Cheers, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: '/usr/bin/[' (was RE: FC12: Hidden files in /usr/bin/*)
On Fri, 2010-01-22 at 08:41 -0800, Cleaver, Japheth wrote: Denis Leroy what about '/usr/bin/[', part of cureutils... had never noticed this one before. -denis Isn't that simply what makes if [ (blah) ] work? It's cute isn't it? I had the biggest grin the day I realised that '[' was just another command.. Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: '/usr/bin/[' (was RE: FC12: Hidden files in /usr/bin/*)
On Mon, 2010-01-25 at 17:44 +0100, Andreas Schwab wrote: Bryn M. Reeves b...@redhat.com writes: nitpick [ may be a built in but then again (as its presence in /usr/bin implies) it may not be :). Like any other command. But unlike '[[' which is the point I was replying to. Afaik you can't provide a '[[' binary and have it mimic the builtin exactly. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
