Re: berlios.de compromised since 2005
Once upon a time, Stephen John Smoogen said: > On Wed, Jan 13, 2010 at 11:33 AM, Jon Ciesla wrote: > > Thanks, Seth. And if we don't, what's a good resource for security > > auditing n00bs? > > 1) Look over the change history. Don't trust the source repository but > older versions of the tar balls and see what has changed between them. To add to this, by "older versions of the tar balls", don't just download an older version from the suspected bad place (as it could have been tampered with as well). For packages that have been in Fedora since before the initial suspected attack, grab an old SRPM from a Fedora archive mirror. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFC PATCH] use sulogin in single-user mode
Once upon a time, Bill Nottingham said: > However, this changes behavior that has existed since the dawn > of time in Red Hat/Fedora systems; with this change, single-user > mode would now require the root password. This is both when > booting with 'linux single/linux S', or going to runlevel 1 > with 'telinit 1'. Well, that would make changing an unknown root password more annoying. At a minimum, you should add the -e option (so if the files are corrupted you can still get in). How about moving /usr/bin/runcon to /bin and using that to call bash instead? In any case, the same method should be used for fsck failures, which right now is sulogin, without the -e (but SELinux is disabled for that shell, which doesn't seem like a good idea to me). I have some old (ancient?) Cobalt RaQs that use sulogin instead of just calling bash, and it is just an annoyance; it doesn't really secure anything (physical access trumps all). If you are trying to secure a system, you need to password-protect the boot loader anyway. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Remove write permissions from executables
Once upon a time, Miloslav TrmaÄ? said: > We can extend the protection to all executables by a simple addition to > redhat-rpm-config (https://bugzilla.redhat.com/show_bug.cgi?id=556897 ). > After applying this patch, executable files in all rebuilt packages > would not be writeable, most often using mode 0555. Please don't take away read permission without good reason. I have on many occasion grepped for strings in binaries (who touches a particular config file for example). There is no reason to remove world-read permission on something anybody can download from their favorite mirror. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Remove write permissions from executables
Once upon a time, Miloslav TrmaÄ? said: > Chris Adams pÃÅ¡e v Pá 22. 01. 2010 v 08:06 -0600: > > Once upon a time, Miloslav TrmaÃ? said: > > > We can extend the protection to all executables by a simple addition to > > > redhat-rpm-config (https://bugzilla.redhat.com/show_bug.cgi?id=556897 ). > > > After applying this patch, executable files in all rebuilt packages > > > would not be writeable, most often using mode 0555. > > > > Please don't take away read permission without good reason. I have on > > many occasion grepped for strings in binaries (who touches a particular > > config file for example). > Just to clarify, the proposal is to remove the write permission. I saw "0555" and thought "0111". Sorry - my mistake. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
Once upon a time, Denis Leroy said: > Speaking on funny things in /usr/bin > > what about '/usr/bin/[', part of cureutils... had never noticed this one > before. Welcome to the past! :-) IIRC "[" has been in /bin or /usr/bin since the late 1970s. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFC PATCH] use sulogin in single-user mode
Once upon a time, Bill Nottingham said: > Jon Ciesla (l...@jcomserv.net) said: > > My thoughts exactly. What are the less simple fixes that don't change > > this behaviour? > > Essentially, introducing new scripts solely for this purpose that can > be given a special label and some policy. It's a hack. It seems that some prefer bash (dash would probably be better as a lighter-weight and less-dependencies shell) and some prefer sulogin (which I think should be "sulogin -e", but that may just be me), and that this should be called from multiple places (single-user mode, fsck failures). It may seem like a hack, but it would seem to me that an external script or program would be the right way to go, to allow people to change it according to local policy. On a desktop system (where it seems the goal is to eliminate the all-powerful "root"), the password may be unknown or not even set, so requiring the root password would be a bad idea. Some server setups may require a password in every case (including failure modes). If it is done with an external script/program, rc.sysinit should be changed as well (and since this should handle SELinux correctly, the disabling/enabling of SELinux could be removed). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sysconfig ifcfg-* support for running custom post-up scripts per interface?
Once upon a time, Richard Zidlicky said: > On Fri, Jan 22, 2010 at 01:08:46PM +0200, Pasi Kärkkäinen wrote: > > It doesn't feel very good to add custom configuration under /sbin. > > same opinion here. I have actually used this for a while, adds one more thing > that needs be verified after system upgrades, not very nice. When I have used this, I usually put ifup-local in /usr/local/sbin and symlink it to /sbin/ifup-local. This way, I can spot it easily as a local script when doing system upgrades, etc. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: packaging shared libraries without autoconf and automake
Once upon a time, Eric Smith said: > I don't want to replace the upstream Makefile with use of autoconf and > automake, and the libtool documentation doesn't really explain how to > use libtool without those. Can I just do the shared library versioning > "by hand", by creating the appropriate symlinks in the package? Or is > there some other preferred way to deal with this kind of situation? If upstream isn't building a shared library, then you have no good way to set a version and then maintain an ABI. If other software that links against the library is only expecting a static, they won't expect to have to deal with ABI changes either. No matter how you make a shared library, I'd suggest getting that change accepted upstream before trying to put it in Fedora. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: packaging shared libraries without autoconf and automake
Once upon a time, Ulrich Drepper said: > On 01/22/2010 08:37 PM, Chris Adams wrote: > > If upstream isn't building a shared library, then you have no good way > > to set a version and then maintain an ABI. > > Not true at all. Why should this be the case? The package maintainer > should ideally _always_ be the one deciding the versioning. I actually > hope this would be done more frequently. The Fedora policy is to push changes upstream, not develop differences from upstream in the Fedora package. Putting shared library versioning in the exclusive hands of the Fedora packagers means we'll be back to the early days of shared libraries, where one distro used libfoo-1.1, one used libfoo-2.0, and another used libfoo2-1.0. That was annoying and confusing, and let to years of people insisting on statically linking everything. Fedora isn't the only Linux. Managing the shared library versioning in Fedora packages means that other distributions can't easily take advantage of it and stay in sync. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
Once upon a time, Ralf Corsepius said: > On 01/27/2010 02:17 PM, Michal Hlavinka wrote: > > Do you think moving this is a bad idea? > Yes. > > The pciutils are valuable tools when trying to recover from situations > when "things go utterly wrong". So what difference does it make where they are (e.g. why do you say this is a bad idea)? They don't work without other stuff in /usr, so they should be in /usr. > > only problem can be with separate /usr partition but because of library in > > /usr it would be already broken and I've not seen any complain about it > > ever. > Well, a separate /usr-partition has never worked on RH-based distros. I beg to differ; I've been using a separate /usr (mounted read-only except during maintenance) on RHL, RHEL, and Fedora for at least 13 years. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
Once upon a time, Ralf Corsepius said: > IMO, you are facing a hen-and-egg problem: You've never seen such a > complaint, because using a separate /usr partition has never worked on > RH-based distros. Please stop repeating this untrue statement. As I told you already, I have used separate /usr since RHL 3.0.3. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
Once upon a time, Ralf Corsepius said: > On 02/01/2010 10:23 PM, Paul W. Frields wrote: > > On Mon, Feb 01, 2010 at 11:16:54AM -0600, Chris Adams wrote: > >> Once upon a time, Ralf Corsepius said: > >>> IMO, you are facing a hen-and-egg problem: You've never seen such a > >>> complaint, because using a separate /usr partition has never worked on > >>> RH-based distros. > >> > >> Please stop repeating this untrue statement. > > You violently don't refuse to understand? That is correct, I am not refusing to understand (that would be you). > RC> Consider having /usr on a separate partition and /usr failing to RC> > mount > RC> at bootup and times at system bootup, during which /usr is not yet > RC> available, because it has not been mounted, yet. > > RC> These scenarios are the key scenarios to separate those parts of a > RC> distros which need to be considered "essential" (have to go into > RC> /lib, > RC> /bin, /sbin) and which to be consider "non-essential". Yes, that's a packaging bug, which started this thread. lspci can't work without stuff from /usr, so it should be moved there, or possibly the needed dependencies should be moved out of /usr. If you know of other problems like this, please cite specifics so they can be fixed, instead of continuing to make vague and unfounded comments that "a separate /usr partition has never worked on RH-based distros". > The "emergency scenario" (/usr not being available) does not work with > Fedora and probably all RH-based distros, because there are packages in > /bin/* /sbin/*, which are dynamically linked against libraries in /usr/lib*. Since when was lspci a mandatory part of an "emergency scenario"? There's enough in /bin and /sbin to edit config in /etc, check partitions, device-mapper, filesystems, etc. You can bring up networking, and (if you are handy enough) fetch files from the network (although it would be nice to move ftp to /bin, since it appears to have no /usr requirements). You have cpio, gzip, and bzip2 (xz should move to /bin as well), and with a little work, you can extract RPMs (although it looks like od is now in /usr/bin; I thought the last time I needed it, it was in /bin). The fact that you apparently can't do any recovery with the working programs in /bin and /sbin doesn't mean that others can't. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFC PATCH] use sulogin in single-user mode
Once upon a time, Bill Nottingham said:
> We have an existing bug where if you're in single-user mode, and
> SELinux is active, various commands don't print to the console.
> The root of this is the single-user shell isn't running in the
> right SELinux context, as there's nothing to distinguish this from
> the 'normal' shells run during bootup.
>
> By far, the simplest fix is to run something that starts a shell
> via a 'normal' login-ish mechanism. Hence, the attached patch
> that switches to sulogin for single user mode.
One other note about this: this would break with a separate /usr and a
failure in mounting /usr, because (at least in F12) /sbin/sulogin is
linked against libfreebl3.so (which is in /usr/lib{,64}). It looks like
libfreebl3.so was moved from /lib{,64} in F11 to /usr/lib{,64} in F12,
but the changelog doesn't say why.
This is already a problem, because an fsck failure tries to start
sulogin (and if the fsck failure is on /usr, you're hosed).
I'd still prefer this to be configurable according to local policy (e.g.
use a /sbin/single-user-shell program that can try sulogin, /bin/bash,
/bin/dash, etc., possibly according to something in /etc/sysconfig).
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Once upon a time, Kevin Kofler said: > I am not willing to silently accept anything with a nonzero probability of > failure on perfect hardware. Any such algorithm is just incorrect. Still using Token Ring because that evil random Ethernet could fail? How do you verify RPMs (or any other signed data for that matter)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Once upon a time, Kevin Kofler said: > IMHO, FESCo should be abolished, Fedora needs to be ruled by the SIGs! Why are you here? All you do is shout about how everything that is done is done wrong, and how you wanted to do it different but were out-voted. Why don't you go start your own distribution? If you are right, then you should have no trouble getting a large group of developers, producing an awesome OS, and then you can prove FESCo wrong. Otherwise, give it a rest. I think everybody knows how you feel, please stop reminding us. There's nothing productive about this. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Once upon a time, Kevin Kofler said: > To me, this includes shipping a great new > technology such as LZMA SquashFS, without waiting for the upstream kernel. You've insisted over and over (and over) again that the KDE SIG should have absolute authority over the KDE packages, and that even FESCo shouldn't be able to set an update policy for KDE packages. Why don't you give the kernel maintainers the same courtesy? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What does the DVD media check if installing a new Fedora version? / Proposal
Once upon a time, Kevin Kofler said: > You can also run sha256sum /dev/cdrom and compare the result with the > published checksums. IIRC, you can in some cases get the wrong value with that due to padding (but it has been a while since I tried that, so that may not be a problem now). If you are looking at the master or mirror directory, you could use dd to only read the right number of bytes from the disk and pipe the output to sha256sum. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Once upon a time, Kevin Kofler said: > Jesse Keating wrote: > > Do you have any sort of proof that it's a "political" reason? It would > > seem to me that our kernel maintainers do not wish to include code that > > hasn't been blessed by Linus in our packages. > > That's political. Again, proof? They have enough patches to sort through every release as it is, and they don't want to add more. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Once upon a time, Kevin Kofler said: > Because LZMA SquashFS is a feature which affects the live images, and almost > exclusively the live images, and as such the SIGs controlling the live > images should be the ones making the decision. SIGs don't exist to exercise control over all packages in the distribution (or all packages that tangentially affect them). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Once upon a time, Kevin Kofler said: > but it's far from easy for somebody who's > not already an experienced upstream kernel developer to manage that, LKML is > a tough place: there's politics making it hard for new contributors to get > their stuff in, there are many rules (technical, cosmetic (i.e. code > formatting rules), and social) you have to learn over the time, I've heard this before, but I didn't find it to be that much different than any other project where I've contributed changes. I think the biggest annoyance was that, because the kernel project is so big and hierarchical, you don't always get a lot of feedback (even when one of the maintainers picks up your patch in their tree to go upstream). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Once upon a time, Kevin Kofler said: > Chris Adams wrote: > > SIGs don't exist to exercise control over all packages in the > > distribution (or all packages that tangentially affect them). > > As I said elsewhere on this list, that's exactly where our organizational > structure fails. That's your opinion, and (many) others disagree. Please stop stating your opinion as fact. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Once upon a time, Kevin Kofler said: > Jesse Keating wrote: > > This is where Kevin blames the scenario on not having the same sqlite on > > all of the Fedora releases, which is another evil plot hatched by the > > devils of FESCo > > Right. If F12 has a buggy SQLite, then that SQLite should be fixed! What if it isn't a bug, but just different behavior? To do such an update in F12, you need to audit the other users of SQLite (of which there are many) and check them against a new version, possibly updating many dependent packages as well. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Once upon a time, Kevin Kofler said: > The people who voted them in were a small minority As were the people that voted you in. Does that invalidate your FESCo standing as well? > I tried many things, even running for FESCo and getting voted in. As you can > see, it didn't achieve anything either. Is it impossible for you to accept the fact that not everybody agrees with you on the direction of Fedora, and that maybe (just maybe) you are in the minority? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Staying close to upstream"
Once upon a time, Kevin Kofler said: > Rahul Sundaram wrote: > > The current approach of trying to force maintainers to accept patches > > simply does not work. > > The only reason it doesn't work is that our organizational structure is not > built to make this work. But why should it be made to work? Why should the KDE SIG be able to force the kernel maintainers to take a patch? What if that patch conflicts with one another SIG wants - who "wins" (if you can call it winning)? SIGs should stick to their area of expertise. The KDE SIG should work on KDE packages and not assume they know what's best for the rest of the distribution. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Once upon a time, Kevin Kofler said: > If we really are the only ones true to Fedora's original principles As I recall, "upstream, upstream, upstream" was one of those principles that you are demanding others now break. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and filesystems with noauto
Once upon a time, Lennart Poettering said: > So, to turn this around. Do you think this behaviour is problematic? Can > you make a good case for dropping this automatism? If so I'd be willing > to do so. The fact that "noauto" in /etc/fstab is documented to not automatically mount filesystems means that they shouldn't be automatically mounted. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and filesystems with noauto
Once upon a time, Lennart Poettering said: > Well, we took the liberty to interpret noauto a little bit differently > than you: everything marked "auto" will be mounted at boot, and boot > will not proceed until all devices listed as auto appeared and are fully > mounted (or things timed out). File systems marked as "noauto" won't > delay the boot process if they aren't, but they'll still be mounted when > they are plugged in, regardless whether that is at boot or during > runtime. Please take the liberty to implement "noauto" as documented. See "man mount": noauto Can only be mounted explicitly (i.e., the -a option will not cause the filesystem to be mounted). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Once upon a time, pbrobin...@gmail.com said:
> Neither of those need to run a MTA locally to work, you just need to
> point them to a mail server, even then they need to be configured to
> send the mail to something other than root anyway.
They can't be configured that way; they don't implement SMTP. It is a
de-facto standard for Unix programs to send mail by piping the message
to either /bin/mail or /usr/{sbin,lib}/sendmail. That has the advantage
of queueing for later delivery (what if I'm off-line when mdmonitor
detects a failure?) and such.
Having to implement SMTP in every program and then configure every
program for SMTP server settings (including possible AUTH and SSL/TLS
parameters) is a really bad idea.
I'm still of the opinion that there should be _something_ at the
de-facto standard location of /usr/sbin/sendmail that can queue messages
for later delivery. I don't care whether it is actually sendmail or
not. Preferably, it should be something that can be easily configured
to smarthost and use SMTP AUTH. I would use sendmail for that, but
that's just me (I understand many don't want sendmail and I have no
problem with that).
What do we gain by not having any MTA installed (other than a little bit
of disk space)? I understand that "a little bit of disk space" can add
up quick, but a local queueing MTA is a pretty standard part of a Unix
system.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Once upon a time, Michael Cronenworth said: > Chris Adams wrote: > > What do we gain by not having any MTA installed (other than a little bit > > of disk space)? I understand that "a little bit of disk space" can add > > up quick, but a local queueing MTA is a pretty standard part of a Unix > > system. > > Why are you complaining? If your package needs an MTA - put in a Requires! It seems that this thread is trying to eliminate those requirements. The mdadm package doesn't currently require MTA (needed for monitoring). If the Requires was added, what would be the response (since the proposal is to remove any MTA from the default package set)? > Why do we need packages installed "just because?" I guess I assumed that Fedora is still providing a Unix-like system. There are a number of things in the Base package set that are there "just because" this is still a Unix-like system, not because they are required by any other installed software. How many users use "at" or "bc" (well, I use "dc" all the time)? What about "ed"? Nothing directly depends on them (except for the LSB package, which also requires "/usr/sbin/sendmail"). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Once upon a time, Michael Cronenworth said: > What benefit do I, or anyone else, receive by shipping a 100% Unix-clone > environment >by default Unix-like be necessary for much longer? Are we making a Fedora for > people to use or for researchers to study? So, according to you, Unix-like systems are only for researchers to study? How does "PCs evolving every 5-10 years" have any bearing on being Unix-like or not? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
Once upon a time, Lennart Poettering said: > On Tue, 24.08.10 15:55, Matthew Miller (mat...@mattdm.org) wrote: > > This is a very big change. chkconfig has worked for a long, long time. Its > > elegance and simplicity is one of the nice administrative features of Red > > Hat based distributes. People like it. > > Yes, and they should continue to use it -- for sysv scripts. I thought the last big discussion resulted in agreement that chkconfig and service should continue to work for all services. Is that not the case? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
Once upon a time, Kevin Kofler said: > Right. In fact, I think we're supporting way too many deprecated > alternatives for way too long, e.g. when will the old legacy "network" > service which has been deprecated for ages finally be gone? Hopefully not before there is something capable of replacing it. Maybe you don't have bridges, 802.1q VLANs (and even bridged VLANs), etc., but last I checked, NM didn't handle them. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Once upon a time, Adam Williamson said: > We're going in circles. I already said that I think the best fix for > this is to replace sendmail with an MTA which works 'out of the box'. You need to define "works". sendmail has always worked out of the box for some things, including sending mail from local programs to remote email addresses and delivering mail from local programs to local users. What more do you want an MTA to do at install? It was decided a long time ago that the MTA shouldn't listen for remote SMTP connections by default. Pretty much any other thing I can think of (such as delivering root mail to a non-root user or smarthosting, possibly with authentication setup) requires manual configuration in any case. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Once upon a time, Garrett Holmstrom said: > While it may be debatable what benefit one might get from removing it > from the default install, can we at least remove MTAs from @core to help > make things easier for appliance folks? One can still go in @base, > which would make it continue to appear on all but the most minimal of > installs. Yeah, I just noticed tonight that sendmail is in both @Core and @Base (as well as @Mail Server). Is there a particular reason it is in both? Right now, it (or whatever the default provider of /usr/sbin/sendmail) should be in @Core, because cronie is mandatory and requires /usr/sbin/sendmail (until the rawhide version of cronie, which will log to syslog if there's no /usr/sbin/sendmail). Why is sendmail also in @Base? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
Once upon a time, Jesse Keating said: > >Why is sendmail also in @Base > > You can opt out of base but not core. If any changes are made it should be so > that one can install just core and not get an mta. Yes, I know that. I was wondering how it ended up in both (if there's a reason and it isn't just an accident, that might have some bearing on removing it from both). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
Once upon a time, Chuck Anderson said: > NM can use old style /etc/sysconfig/network-scripts/ifcfg-*. Can't > you just write those out from your %post section? Or, if you want all > the NM features like WPA wireless config, you can use the keyfile > plugin to write NM ini-style key-value files. Either way, those are > text files that are easily handled from shell scripts. This is rather under-documented I discovered last night. There is a document that describes the keyfile plugin config, but it doesn't appear to be on the NM website, and it isn't included in any Fedora RPM as far as I found. I opened BZ 627782 about this; the spec file takes steps to keep the timestamps on docs (for multilib), but then only includes a single file (the library API) in an RPM. The ifcfg-rh plugin doesn't appear to have any documentation at all (from what I understand, it doesn't support all the same things in network-scripts that ifup/etc. do, and it adds some things of its own for WPA and the like). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
Once upon a time, Tom spot Callaway said: > I assume nmcli doesn't meet the requirements? nmcli manages connections (up/down), but AFAIK doesn't support configuring them or creating new connections. I didn't find a CLI tool for creating/configuring NM connections other than the universal "vi" (but then the config files are not well documented). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
Once upon a time, Sven Lankes said: > Also - and this is a question that I have asked myself and others a > couple of times - if you could implement Fedora the way you want: What > unique selling points are left for Fedora? "Fedora is Ubuntu with rpm" > sounds about as bad as "Fedora is broken most of the time" (not that I > feel it is). I guess I've never been concerned about "unique selling points". Why should it be "Fedora is Ubuntu with RPM", instead of "Ubuntu is Fedora with DEB"? IIRC Fedora came first (and certainly RHL came before Ubuntu, although Debian was little before RHL). I like Fedora because it is free and Free. The development is handled by a community, not just a single company. Also, RHEL is developed out of Fedora, and I use RHEL on my servers at work, so Fedora is a bit like a window into the future of RHEL. I first moved from Slackware to RHL (3.0.3 in 1996!) after having built a system of my own from the ground up (compiling everything from source manually, keeping notes along the way). I appreciated how RPM worked immediately after that experience. When I found bugs and emailed them to Red Hat, somebody fixed them. Once RH BZ was set up, I opened a bunch of early bugs (5 of the first 60, several including patches), and generally got a good response. I worked with the RHL Betas for a few years, until this crazy experiment of a community distribution called Fedora came along. I like the release schedule of Fedora, but I don't like the idea of each release continuing to be a rolling update target. I don't really understand why about six months (or less if you didn't install on release day) is such a horrible wait to make big changes to the system. If the up-to-six month wait is the problem, I'd rather see more releases (e.g. "Fedora 14.1: Now with GNOME3!") with more targeted/focused changes. That's probably not practical with the available manpower however. Why do we need to be concerned about being similar to or different from Ubuntu? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag support?
Once upon a time, Eric Sandeen said: > Some things to test would be attempting to defrag files > which are being actively written to / read from in various > ways - concurrent access, mmap, etc. Also make sure to test files used by sendfile() and splice()/vmsplice(). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
Once upon a time, Bruno Wolff III said: > Some have > also hoped that Mozilla would change with regard to bundled libraries in the > near future, but that seems pretty unlikely. I think that's an unfair statement; from what I understand, Firefox has already unbundled some libraries, and said they will unbundle others once their changes settle down. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
Once upon a time, Bruno Wolff III said: > On Mon, Oct 11, 2010 at 11:41:13 +0100, > "Richard W.M. Jones" wrote: > > > > Some of the things it does which are IMHO better: > > > > - starts disk formatting / copying / installing in parallel > >with asking user questions > > I think that is a misfeature. I don't want anything irreversible to be done > until I say go. You know that Fedora has done partitioning/mkfs about halfway through the install for a while now, right? I don't see why there would be a problem with letting that run in the background while continuing through the questions. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ethtool not in default system anymore?
I noticed that ethtool is not in the default install anymore (probably for a release or so, but I didn't notice it until now). Why is that? It is the only tool that can show and configure a variety of network device options, such as speed/duplex negotiation, wake-on-LAN, and TCP offloading. There is support in the ifcfg-eth* files for calling it as part of interface setup (don't know if that's carried forward to NM, should be considered a bug in NM if not). Is there a replacement that I'm not aware of? I have run into flakey switches and such where you have to force speed/duplex to communicate (yes, such switches are crap, but when it isn't your network, you don't get to choose). Not having a tool to do that already installed makes it impossible to fix. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
Once upon a time, Gregory Maxwell said: > On Tue, Oct 12, 2010 at 7:28 PM, Chris Adams wrote: > > I noticed that ethtool is not in the default install anymore (probably > > for a release or so, but I didn't notice it until now). Why is that? > > It is the only tool that can show and configure a variety of network > > device options, such as speed/duplex negotiation, wake-on-LAN, and TCP > > offloading. There is support in the ifcfg-eth* files for calling it as > > part of interface setup (don't know if that's carried forward to NM, > > should be considered a bug in NM if not). > > mii-tool. Does that work with all NICs now? I used to run into NICs that it didn't handle (but ethtool did). I haven't looked at mii-tool in a while though. In any case, that handles one thing that ethtool does (speed/duplex); what about the rest? Also, AFAIK there's no nice hook to run mii-tool (or anything else) in ifup-eth like there is for ethtool. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
Once upon a time, Jesse Keating said: > Looking at comps, it seems ethtool was never listed, so it must have > been pulled in as a dep of something (if it ever was installed by > default). I'd say look at your older systems and see what, if anything, > requires ethtool. It looks like up through F12, initscripts required ethtool (so it was definately installed by default). I see this in the RPM changelog: * Mon Feb 15 2010 Bill Nottingham - 9.05-1 - network-functions: don't use ethtool for link state, assorted other cleanups Of course, there's also this: * Mon Aug 03 2009 Bill Nottingham - 8.96-1 - only use ethtool for link checking; no more mii-tool mii-tool gets pulled in by default because initscripts depends on net-tools. However, the mii-tool declares itself obsolete and recommends ethtool. Maybe ethtool should be added to @Base? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
Once upon a time, Michael Cronenworth said: > Chris Adams wrote: > > Maybe ethtool should be added to @Base? > > Or patch initscripts to use ethtool instead of deprecated cruft. You cut out the part of my email where I quoted the changelog showing that had already been done. The net-tools package should be included anyway (although maybe without mii-tool), as it includes commonly used tools like ifconfig, arp, route, hostname, netstat, etc. Even if some of those commands are obsoleted by ip, they are pretty much required for compatiblity. net-tools also has ether-wake for sending wake-on-LAN packets. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug in curl makes Fedora ftp:// URL installations fail with some mirrors
Once upon a time, Chuck Anderson said: > On Sun, Oct 17, 2010 at 02:03:20PM +0300, Pasi Kärkkäinen wrote: > > Yes, indeed, it seems more likely a bug in the FTP server (pure-ftpd), > > but it would be very nice to have a workaround in curl or in anaconda for > > it.. > > Why not fix the the problem at the source? Under the "be generous in what you accept", curl should be changed to handle this (especially if other clients can handle it). Looking at a packet dump, I'm not sure which side is at fault. FTP allows you to specify the start of data (start at offset 1384) but not an end, so the only way to get less than the full rest of the file is to abort the data transfer. It looks like curl just closes the data socket without sending an ABOR on the command socket, so I think the server is allowed to dump the client. It would be nicer for the server to handle this better as well, but I think the problem starts with curl. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, Matthew Garrett said: > On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote: > > This despite the FHS says (right at the top of Chapter 3, the Root > > Filesystem): > > > >/usr, /opt, and /var are designed such that they may be located on other > >partitions or filesystems. > > > > Do we *really* want to head this way, ignoring bugs resulting from > > having /usr on a different partition such as > > http://bugzilla.redhat.com/#626007, which is what led to this? > > What's the benefit in having /usr or /opt as separate filesystems? A smaller / that is written to less often is less susceptible to errors. If you don't allocate enough space for / up front, you can move /usr and /opt to separate filesystems later. /opt can be completely unpredictable in space usage, due to vendor RPMs dumping stuff in /opt (see Dell's OMSA, that puts everything, including logs, under /opt). When disk was expensive, /usr was often the biggest consumer of space, so it would be shared across the network, but that's not a big issue anymore (and RPM doesn't really support shared /usr IIRC). I personally don't use a separate /usr on desktops, only on servers. On my servers, /usr is mounted read-only, as an extra protection against accidental (or even intentional) screw-ups. It also means that I don't waste I/O cycles on updating atimes on often-used binaries and libraries (which of course could also be done with noatime). I've seen some boot-from-flash setups with /usr on a hard drive. Basically, if Fedora is going to follow the FHS at all, bugs like 626007 should be fixed, not ignored because somebody doesn't like a separate /usr. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, Matthew Garrett said: > Because it takes more engineering effort to keep it as a separate > partition, as evidenced by the number of bugs that keep appearing that > are only triggered by this niche usecase. And how many of those bugs are exclusively a /usr-is-separate problem vs. how many of them are didn't-anticipate-alternate-partitioning problems? I don't understand how separate /usr can be the sole trigger for all these many bugs. The only type of bug I can see attributed only to separate /usr are bootup requiring things in /usr before non-root filesystems are mounted. I expect other bugs attributed to separate /usr are really problems handling non-default partitioning schemes of many kinds. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, Peter Jones said:
> On 10/19/2010 11:28 AM, Chris Adams wrote:
> > And how many of those bugs are exclusively a /usr-is-separate problem
> > vs. how many of them are didn't-anticipate-alternate-partitioning
> > problems?
>
> If I understand your distinction correctly, then the overwhelming majority
> of them are the former.
The one that led to this discussion (626007) doesn't seem to be.
The "/usr/sbin/foo is needed before FSes are mounted" is a fairly
trivial problem to solve in the majority of cases; I don't see that as a
big deal.
If separate /usr isn't considered a valid configuration, why do we have
separate /bin, /sbin, /lib{,64}?
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, James Antill said: > Putting my really old sysadmin hat on, one other reason for > having /tmp, /var and /usr as separate mount points was so that you > could allocate different disk space to each (and they couldn't break > each other) ... do we have other solutions for that? On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well. You generally don't want logs (which are indirectly user-writable) on a filesystem with other system-critical things, as it leaves you open to DoS. This is really separate from / vs. /usr though, as neither should have directly or indirectly user-writable files (assuming separate /tmp and /var). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, Bill Nottingham said: > Peter Jones (pjo...@redhat.com) said: > > Because we haven't decided to merge those together. That's really the only > > reason - there's no over-arching technical reason they need to be separate. > > It's entirely a historical consideration. > > Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, > and so on were just symlinks to /usr/bin, /usr/lib, and so on. On Tru64 (aka Digital Unix aka OSF/1 aka ...), /bin is a symlink to /usr/bin, and /lib to /usr/lib (but shared libraries are in /shlib and /usr/shlib, and they are separate; the lib directory is primarily for compiling). All the stuff needed for early booting is in /sbin (separate from /usr/sbin). I don't even think you can install with /usr (or /var) on the same filesystem as /. However, with AdvFS, the root file domain is special (with extra restrictions due to the bootloader and other things), so you really don't want anything else in there. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who broke fedoraproject.org usability?
Once upon a time, Tom spot Callaway said: > Also, it is worth noting that the new website makes heavy use of > Javascript, so if you have NoScript (or equivalent) running, you'll not > get a good view of the site. :) Yeah, apparently that was the problem I was seeing. Honestly, making a site that looks broken with NoScript is a bad idea, especially for a user base that probably has a higher-than-average number of Firefox users (and probably mode advanced users that are likely to use things like NoScript). Requiring JavaScript just to get the correct layout is IMHO broken. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
Once upon a time, Przemek Klosowski said: > On 07/26/2011 12:49 PM, Richard W.M. Jones wrote: > > >> PATH=$PATH:$HOME/.local/bin:$HOME/bin > > > > This was added between bash-4.2.10 -2 and -3: > > > > http://pkgs.fedoraproject.org/gitweb/?p=bash.git;a=commitdiff;h=02b20d810111e8b53bb98ad49fedd1d583ce62e1 > > > > because of https://bugzilla.redhat.com/show_bug.cgi?id=699812 > > > > There is some rationale in that bug, but I think it's extremely bogus. > > Specifically, Lennart said that it was required by XDG which he > coauthored :) Well, ~/.local/share is the default for data. The XDG spec found here: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html makes no reference of ~/.local/bin (or any other directories under ~/.local). IMHO adding directories to the default path should get a little more discussion than a single BZ request (and probably shouldn't be changed mid-release without notice). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
Once upon a time, Matej Cepl said: > Dne 26.7.2011 20:40, Bernd Stramm napsal(a): > > Oh it seems every useful for purposes like installing executables that > > most users will never find. > > Actually I would prefer ~/.local/bin to ~/bin ... I actually use ~/ as > my workspace (I never got what's the point of ~/Desktop) so I don't > want to dump there a random junk. Until now I used ~/.bin but > standadized location would be certainly better. I've used ~/bin since before Linux was available, so I don't really see the point in trying to "hide" it (of course, I alias ls to "ls -FCA", so ~/.bin wouldn't be hidden, just one extra character to type when I need to access it). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
Once upon a time, Bryn M. Reeves said: > I just assumed it was by analogy to /usr/local - a per-user directory for > local > installation with a structure mimicking /usr. But the user already has the whole home directory. On RPM-managed systems, the different between /usr and /usr/local is that /usr is RPM managed and /usr/local is not. ~/ is already not RPM-managed. ~/bin has been in the default PATH for many years; why do we need a second such directory? The source of /usr/local was NFS-mounted /usr, with /usr/local being on the local system. ~/ would typically be NFS mounted in that type of setup (users don't get space on the local drive except /tmp), so ~/.local would be meaningless. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Once upon a time, Tim Waugh said: > On Wed, 2011-08-17 at 20:04 +0530, Rahul Sundaram wrote: > > https://fedoraproject.org/wiki/Starting_services_by_default > > Ah, thanks. So it looks like CUPS can be enabled by default: > > "If a service does not require configuration to be functional and is not > network enabled, it may be enabled by default" Is CUPS functional without any configuration? How do you print without configuring a printer? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
Once upon a time, Jon Ciesla said: > > On 08/29/2011 05:24 PM, Karel Zak wrote: > > IIRC, you are upstream for this and could do this change upstream and > > then, there wouldn't be a debate about this here. Otherwise, make > > ddate a sub package and don't install it by default. Solved? > > > Acceptable to me, but is the extra metadata for another RPM worth the > space savings? Is that why this is being done? Space savings? On my F15 system, ddate, the README, and the manual pages account for 22k. If space is the justification, there's lots of better places to start. Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)? How many tools do we really need for partitioning disks and managing partitions (util-linux has fdisk, sfdisk, cfdisk, partx, blockdev, all with associated documentation)? Note: I am NOT saying any of that should be removed. I'm just saying that "space savings" as justification of removing ddate is stupid. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Kevin Kofler said: > No, it means that (unless this was recently fixed) you have to modprobe it > manually (e.g. from rc.local) because nothing bothers trying to modprobe it > for you anymore. IMHO, this is really broken, but the bug reports about it > were ignored or declared NOTABUG. It is very irritating, since I only use floppies when I really need to, and usually I've upgraded the system (I typically do clean installs) since the last time. I always have to stop and manually configure the floppy drive again. For a while, USB floppy drives got correctly configured when you plugged them in (a udev rule was added to get /dev/floppy links and ownership), but that was removed somewhere along the line. I own the package for formatting floppies in USB drives (ufiformat), and it is also irritating when I go test it for new releases. With changes over time, I don't know how to get the device nodes with the correct access for the desktop user anymore, and I figure if somebody went to the trouble of removing the udev rules, there's not much point in asking to have them added back. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Once upon a time, Michael Cronenworth said: > On 08/29/2011 10:22 PM, Chris Adams wrote: > > It is very irritating, since I only use floppies when I really need to, > > Is this due to the need to boot into DOS to run a firmware utility or > something similar? If so, you can create a bootable, DOS USB flash > drive. I haven't had a need for a floppy disk in years. That's nice that you haven't needed one, but I have. I try all kinds of alternatives first (up to PXE booting syslinux to load memdisk and a floppy image), but I have run into things that just really need an actual floppy. It isn't why I use floppies under Linux, but my mother's very expensive computerized embroidery machine uses floppies to transfer patterns. There are still things in the real world that exclusively use floppy disks, and they aren't going away as rapidly as some seem to think. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Once upon a time, Jef Spaleta said: > Bah, I'd think you'd want to go the other way if you could get an external > usb based floppy reader which is autodetected on the usb bus. Anything that > hangs off the onboard floppy controller is going to need some lovin. These are for embedded systems that use a standard PC-style floppy controller. Replace the floppy drive with something else that still looks to the system like a regular floppy drive. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Simo Sorce said: > Making boot hang for long periods can easily be seen as 'Not working > properly' and therefore make default floppy support 'not possible'. > At least this is the reasoning I see and agree with. How many systems are there that "hang forever" when the floppy module is loaded? I have never seen that happen, on systems with or without floppy drives, yet you seem to be saying it happens on vast numbers of them (99.9% in an earlier message). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Simo Sorce said: > I said: > A) 99.9% of users do not needed the floppy anymore > B) I said hang for "long periods" and not "forever", where here "long" > is of course relative to modern machine boot times. You said: It seem much more intelligent to add a package owners of floppies can install, so that 99.9% of the others do not have to wait forever for no reason. http://lists.fedoraproject.org/pipermail/devel/2011-August/156261.html To me, that reads as "99.9% of non-floppy owners have to wait forever". In any case, instead of arguing semantics, can you answer my actual question? How many systems hang when floppy.ko is loaded? If it is a large number, it should be easy to point to lots of data. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Simo Sorce said: > They do not 'hang', they just take longer to boot, sometimes a lot > longer. How much longer? How many such machines? Again, I've booted systems without floppy drives but with floppy support loaded, and I haven't seen any significant hang. Leaving known-working hardware unusable at install is just rude and irritating when it is needed. There should be good justification, not just "a bunch of developers don't use it anymore, so we don't think anybody else needs it". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Once upon a time, Chris Jones said: > I see it all the time. "Some older hardware still requires floppies..." It > just seems like a generic defense statement for the fans of floppies and for > those who insist on using them for god knows what reason. Again, please stop trying to tell me what hardware to use. I have run into several situations where I _must_ use a floppy. I don't want to, and I've tried lots of other things first, but the floppy worked. > Any hardware that is true to that statement must be at least 15 years old > surely! Hardly. I have a 6 year old notebook that will not book from USB. > And for the cheap price of PCs these days, whether it is building your own > or grabbing an oem system, just upgrade to something that does have full usb > support. Feel free to PayPal me money for a new notebook. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Once upon a time, Hans de Goede said: > anaconda loads the floppy driver by default when booting of the install > DVD, because of driverdisk support, thus the anaconda team has been getting > its share of bug reports wrt this. But AFAIK there are no such issues > in RHEL-5, where we auto-load the floppy driver too, so something > has changed in the kernel causing the hang when no drive is attached to the > controller. I could swear I filed a bug against the kernel about this > regression, but I cannot find it. So, it sounds like it is a kernel bug, and the "fix" was to just ignore it and stop loading the module. ... -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Once upon a time, Bruno Wolff III said: > Below is a proposed specfile for the floppy case. (Analog joystick would be > very similar.) I haven't tested the package for functionality yet, but did > test it with rpmbuild and rpmlint. Is this what we want? Is this ready > for a formal review? That loads the module, but what about configuring device access for desktop users? That's the more irritating part to me (that has changed over time and I no longer know how to fix it). Once loaded, the floppy device should be treated just like any other removable media device as far as user access is concerned. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora kernel bug day.
Once upon a time, Dave Jones said: > Hardware specific problems like this are a nightmare for us to diagnose. > It might even come down to you needing to do a bisect to find the individual > kernel change that caused the problem. (assuming you know a 'good' version > to start from) I know suspend is another "fun" area, but are there any good tools to figure out what is wrong when suspend/resume doesn't work right? I've got a problem system (RH BZ 548593) that I don't know what else I can do to try to fix. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Once upon a time, Matthew Garrett said: > Like I said, that works fine right up until the point where you plug in > a monitor with a different DPI. What do we do then? I would wager that the majority of Fedora systems are single monitor (or, in the case of notebooks, single monitor much of the time); can't we at least try to correct for that case first, and _then_ try to deal with multi-monitor setups? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
Once upon a time, Bill Nottingham said: > Obviously you embed radar in every projector. Projectors with auto-focus already detect the distance to the screen (I think they use IR). I don't expect that they change the EDID screen size reporting though. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
Once upon a time, Orcan Ogetbil said: > On Wed, Oct 12, 2011 at 12:44 PM, Kevin Fenzi wrote: > > New Password Rules: > ... > > * No maximum length. > > I thought about this for a while. Is this ever possible? What kind of > storage do we use? Yeah, I saw that too. A literal "no maximum length" is a denial of service waiting to happen. I'm sure the passwords are hashed, so it isn't a matter of storage, but the input buffer is not unlimited, and neither are the hash iterations to process the input. What is the actual limit? 256 characters? 512? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BEWARE: a problematic glibc made it to stable (F16)
Once upon a time, Adam Williamson said: > Oh - and remember, the goal of the critpath process is to ensure we > don't send out updates that break people's systems. It worked fine in > this case: no glibc update which breaks systems was approved. All the > ones which caused major runtime breakage got rejected. The only breakage > in one which was approved was to do with compiling things - which, sure, > is a pain in the ass, but it's not the kind of problem critpath was > introduced to deal with in the first place. That's splitting hairs; you're assuming that no Fedora users use their system to compile things. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
> === > #fedora-meeting: FESCO (2011-10-24) > === > * Discussion about https://fedoraproject.org/wiki/Features/UsrMove > (t8m, 17:26:45) This sounds interesting (speaking as an admin that typically sets up servers with separate, ro-mounted, /usr). I'm not sure about moving _everything_ to /usr, but I guess that's one approach. Other Unix systems I've used have had /bin as a symlink to /usr/bin, but not /sbin (still kept core system maintenance tools in /sbin on root fs). I'm also not sold on eliminating sbin directories (I like having "system admin" type stuff kept separate), and I don't see why that needs to be rolled into the same feature (especially as just a footnote, not a top-line change). One big question though: can RPM handle such a change? IIRC, when the switch from /etc/rc.d/init.d to /etc/init.d was made, initially everything was going to be moved and the old paths symlinked for a few releases. However, there was some problem with RPM that couldn't handle switching an existing directory to a symlink, so that change was reduced to introducing /etc/init.d as a symlink. How will upgrades be handled if this feature goes through? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Michał Piotrowski said:
> Cool idea. Next I suggest to stop using
> /bin
> /sbin
> /lib
> /lib64
> in F19, and not to create these links on freshly installed systems in F20.
That will (or at least should) never happen. You might could eliminate
/sbin, but there are several things in /bin that are established
standards (such as /bin/sh for shell scripts). /lib{,64} is part of the
ABI because of /lib/ld-linux.so.2 and /lib64/ld-linux-x86_64.so.2.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Michał Piotrowski said: > In any case > #!/usr/bin/env sh > seems to be more portable solution. Using env has always been a hack (and overhead, especially on otherwise short shell scripts). As for "portable", /bin/sh is as portable as it gets. I doubt there has been a significanly used Unix-like system since 7th Edition that didn't have a Bourne-like shell at /bin/sh. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Michał Piotrowski said: > I created feature page > https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters I strongly object to this "feature". /bin/sh is a Unix standard back to IIRC around 7th Edition, and there is NO good reason to break it. The "#!/usr/bin/env foo" suggested replacement has always been a hack to work around broken systems, not something suggested for all scripts. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Michał Piotrowski said: > 2011/10/25 Chris Adams : > > Once upon a time, Michał Piotrowski said: > >> I created feature page > >> https://fedoraproject.org/wiki/Features/F18MorePortableInterpreters > > > > I strongly object to this "feature". /bin/sh is a Unix standard back to > > IIRC around 7th Edition, and there is NO good reason to break it. The > > "#!/usr/bin/env foo" suggested replacement has always been a hack to > > work around broken systems, not something suggested for all scripts. > > What is wrong with > #!/usr/bin/env interpreter > from technical POV? It is an unnecessary hack, since the intepreters all have standard locations. It also adds the overhead of a second exec() call and a PATH search (start env, let it parse its command line, then search the PATH for the desired interpreter, then exec() the interpreter). It also makes system scripts more fragile; for example, if somebody installs (from source) a different version of python in /usr/local/bin, all RPM-installed scripts in /usr/bin (that may not even work with that version) will now use the new version with unpredictable results. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Bill Nottingham said:
> I'm not sure why this would even be discussed.
>
> ln -s /usr/bin /bin, and move along to other business.
I think someone proposed (as an addition to UsrMove) having the /bin,
/sbin, etc. symlinks deprecated and to remove them in a couple of
releases. IMHO aside from necessary compatibility (such as the dynamic
loader being in /lib{,64}), there's way too much history involved in
/bin (and to a lesser extend /sbin) to ever consider removing the
symlinks.
More importantly, there's no compelling reason FOR removing them, other
than somebody's idea of neatness. I have no problem removing compat
symlinks when they are no longer needed; I just don't believe that will
ever be the case for /bin, /lib{,64}, and /sbin.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
Once upon a time, Richard W.M. Jones said: > Having said that, the split between /sbin and /bin is not a truly > historical one, ie. it didn't exist in V7. I think it was added by > System V which did a lot of other strange stuff too. Well, historically, a bunch of system utilities were in odd places like /etc and /usr/lib. The idea of /sbin and /usr/sbin was to get compiled executables out of those places (and to not clutter up the "normal" bin directories with stuff users didn't need). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
Once upon a time, Harald Hoyer said:
> For daemons, which should not be called directly on the command line, I
> would suggest to move them to /usr/lib// anyway.
That's what /usr/libexec is for. /usr/lib{,64} is for libraries and
such, not executables.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Harald Hoyer said: > About "sbin": How exactly does "hiding" stuff prevent users, who open a > _shell_, to use those tools? They cannot do any bad stuff with it anyway. It isn't about hiding, it is about not putting tools in your PATH that you generally can't use anyway. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
Once upon a time, Chris Adams said: > One big question though: can RPM handle such a change? IIRC, when the > switch from /etc/rc.d/init.d to /etc/init.d was made, initially > everything was going to be moved and the old paths symlinked for a few > releases. However, there was some problem with RPM that couldn't handle > switching an existing directory to a symlink, so that change was reduced > to introducing /etc/init.d as a symlink. How will upgrades be handled > if this feature goes through? I haven't seen this part addressed, and the more I think about it, the more I think it may be a show-stopper for upgrades. IIRC the problem is that if there are any files in /bin, RPM can't replace the directory with a symlink. There could be files from third-party RPMs, Fedora RPMs that have been retired but people still have installed, or from local changes/customizations. There is also a problem with the order things are done. RPM can't replace /bin until all RPMs such as bash are updated to versions using /usr/bin, but as soon as you install that bash, /bin/sh %post scripts are broke until /bin is symlinked. For example, if you use the old-style network initialization (instead of NM), the way to do pre/post config per interface is with /sbin/ifup-pre-local and /sbin/ifup-local. If an admin has created those files, RPM can't replace /sbin with a symlink to /usr/sbin AFAIK. This would also apply if somebody added firmware manually to /lib/firmware or built a local kernel and installed modules to /lib/modules. The only way I see to make this work would be to put a change directly into anaconda (before it starts installing RPMs), but then you'd break anybody that tried to "yum upgrade" from an older release (and there are always people that do that). Any anaconda work-around for this would also have to handle filename conflicts among locally-created files (e.g. /bin/foo and /usr/bin/foo). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?
Once upon a time, Tom Lane said: > Any opinions on which way to jump? How hard is it to fix source that accesses the fields directly? Do all the fields that were previously exposed have direct accessor functions? If that's the case, it should be straight-forward (although time consuming) grunt work to get the necessary packages fixed (maybe some of it can even be scripted?). If you can give a basic "replace info.foo with foo(info)" type script, it shouldn't be too hard to get enough help to roll through it (I'd be willing if you can tell me what to do; I've never used libpng directly myself, so I'm not familiar with what is required). Since all the packages that depend on libpng would have to be rebuilt twice if you don't go to the latest version now, I'd say go ahead and get it over with once (i.e. go to 1.5). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xfce-weather-plugin stopped working
Once upon a time, Heiko Adams said: > yesterday in the afternoon the xfce-weather-plugin suddenly stopped > working and allways displays "No Data". Trying to switch my location > or update my fedora 16 against updates-testing also didn't solve that > problem. Does it use The Weather Channel (weather.com) as its data source? They cut off the old free API and now charge for the new one. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's this /run directory doing on my system and where does it come from?
Once upon a time, Michał Piotrowski said: > First, people are wondering if this change is compatible with some > obsolete specification, next people are wondering if this change is > compatible with distribution feature process. I repeat again, this is > not a feature this is evolution. Lennart uses a big hammer here, but > from a technical POV these changes makes sense. Please stop calling FHS obsolete, at least as long as the Fedora packaging guidelines say it should be followed. I think the problem here is how this was done, not as much what was done. Would it have been so much trouble to have discussed this in advance? The FHS allows dsitros to add additional top-level directories, but this was done by developers of a package, without any distro discussion. We're well past F15 Alpha and almost to Beta; IMHO a change like this should have been made sooner (or wait until next release). There may be things that the systemd developers didn't think about (what about SELinux policy for example; I haven't seen that mentioned). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's this /run directory doing on my system and where does it come from?
Once upon a time, Ralf Corsepius said: > How about /var/run ?? > > What would be wrong with it? I believe the need is for something guaranteed to be on the root filesystem, and having a separate /var is still valid. I'm not sure why this doesn't go under /etc, but if I were king, the proliferation of kernel filesystems (proc, sys, cgroup, selinux, etc.) would be under /kernel, so maybe that's just me. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What's this /run directory doing on my system and where does it come from?
Once upon a time, Lennart Poettering said: > /etc is static configuration data. There are a number of things under /etc that are not static configuration data. > /etc is read-only during boot. > > /run is writable all the way. /etc/run could be too. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Beta RC1 Available Now!
Once upon a time, Dennis Gilmore said: > Chris its the teminology we have always used. > each phase has a series of release candidates. I thought they were called "test composes" or TC, not RC. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Beta RC1 Available Now!
Once upon a time, Jesse Keating said:
> Would it make more sense to refer to these as "Alpha Candidate", "Beta
> Candidate" and "Release Candidate" ? ac{1,2,3}, bc{1,2}, rc1 ?
That sounds good to me; each is distinguished frmo the other and clearly
describes what it is.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Once upon a time, Nathaniel McCallum said: > With this approach, you have lost a critical feature: the ability for > you to change your hardware (or move the software bits to a different > computer) and have everything automatically work. That has been the case off and on for a long time, with kernels and glibc split for i386/i686, and then kernels for PAE. Old hardware is always going to fall off the tail. It isn't like the packages are going to be removed, and they'll probably not get any less testing than they do today. Also, since VESA will still be included, it should work on most any hardware. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Once upon a time, Jeff Garzik said: > Data centers have /plenty/ of ancient video solutions out there, and > basic video support is needed. How many data centers run X on servers? I know I don't; they all boot runlevel 3 and just have a serial console (KVM switches are for Windows machines). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
Once upon a time, Lennart Poettering said: > The place for system configuration is /etc. I have yet to see a really > convincing example why /etc/sysconfig/ or /etc/default would win us > anything. /etc/sysconfig is essentially configuration for the init system managing daemons. Command-line options, which sub-bits to run, etc. that are not settable in the daemon configuration files themselves. I think having them in a sub-directory is much cleaner (and makes them easier to distinguish from the "regular" daemon config files). I don't think /etc/default is a good name (if that indeed is what Debian uses), because they are options you change to get non-default behavior. > I am pretty sure that the vast majority of files in there are > pretty much unnecessary and their configuration could be solved in a > different way much nicer. I've used a bunch of them to change the ways various daemons run, so I would definately say they are not "pretty much unnecessary". They are also shell scripts that are sourced by init scripts, so there is flexibility to make changes that may not have even been anticipated by the init script authors. Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either. > So yeah, I'd push for phasing /etc/sysconfig out for most services, not > standardize it. I'd be 180 degrees from that. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wireless-tools/net-tools are DEPRECATED
Once upon a time, Kevin Kofler said: > Newsflash: the network service is DEPRECATED!!! That's what NetworkManager > is for. Newsflash: NM doesn't replace the network service yet. Maybe when NM can do everything ifup/ifdown can do, the discussion about deprecation can happen, but until then, please stop saying NM replaces the network service. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ipv6 tools + ipv4 tools fusion.
Once upon a time, Wes Hardaker said: > I'm all for a single unified set of commands (-4, -6). The real > question, is what should the default be? And if 4 now, when do you > switch later? [thus, I think -both now with v6 first if a is > available otherwise v4 is probably the right answer] The same host selection algorithm used in glibc (per the relevand RFCs) should be used by all tools, unless a -4 or -6 override is given. This way you can "ping foo.bar.com" and turn around and "ssh foo.bar.com". Right now, since ping and traceroute are different, you can get confusing results (for example, in the face of some broken IPv6 setups). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: use /etc/aliases or /etc/mail/aliases?
Once upon a time, Genes MailLists said: > If I recall correctly - the old sendmail way was /etc/aliases - the > new sendmail way is /etc/mail/aliases .. as far as I know that has the > default for sendmail for some years. Yes, but Red Hat's default sendmail config overrides that to continue to use /etc/aliases. I believe postfix also uses /etc/aliases (don't know if that is also a RHEL/Fedora change from upstream default); I don't know about other MTAs. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15's /usr/include/rpc has disappeared; uncompilable
Once upon a time, Adam Williamson said: > In fact, you can see this has already happened: > > https://admin.fedoraproject.org/updates/glibc-2.13.90-11 > > has -6 karma at present. When it hit -3, it got unpushed. Yeah, but -10 had the drop of RPC, so the damage is already done. -10 was broke (in that IIRC netdb.h still tried to include rpc.h), so an update will still be needed or a completely broke setup will be shipped. IMHO the drop of RPC should be rolled back for F15 (e.g. back to the way the glibc -9 package looked), as this is WAY too late in the game to be changing the core library like that. A change like that should land in rawhide long before release (right now for F16 would be good), so FTBFS can be found, requirements updated, and possibly patches generated. What was the justification for pushing an updated glibc post-beta? Aren't critpath updates supposed to be approved post-beta (or am I misremembering the process)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
Once upon a time, Josef Bacik said: > These sort of issues are my priority and I've spent the last 2 months > specifically working on the kvm performance differences between ext4 > and btrfs. Now we're not on par with ext4 yet, but we aren't 2-3 > times slower any more, maybe at the most we're 20% slower. Thanks, How does it compare to straight LVM for virtual images? I create a big LV and then only use part of it for the host OS VG; when I create VMs, I create a VG for each (or I can snapshot an existing "base" VG). It is my understanding that one goal for btrfs is to take LVM out of the picture for the common case; i.e. btrfs can do its own logical volume management. If that's the case, there needs to be something comparable to the VM-on-VG setup (in terms of ease-of-management and performance). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
Once upon a time, Stephen John Smoogen said: > I wonder if the btrfs solution would be that you would just use raw > partitions and not use btrfs for it. > > eg > /dev/sda1 is /boot > /dev/sda2 is swap > /dev/sda3 is btrfs / > /dev/sda4 is VM-01 > /dev/sda5 is VM-02 That would work, but that loses a lot of functionality such as resizing guests without rebooting (either the host or the guest), snapshots, etc. I usually set up the host OS in the same VG as the guests, so I can add space to the host storage as well as guests, all from the same pool. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
Once upon a time, Richard W.M. Jones said: > 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. > > However the performance issue will be critical -- even 5% slower > really matters for VMs. But I hope btrfs can close this gap because > the filesystem design is really nice. That was really my original point (that I didn't really state clearly I guess); btrfs performance with VM disk images should be compared against LVM VGs as well against ext4. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: impending IPv6 Test Day
Once upon a time, Josh Stone said: > On 06/21/2011 05:54 AM, Andreas Schwab wrote: > > David Woodhouse writes: > > > >> And curl is just broken for numeric IPv6 addresses completely: > >> > >> [dwmw2@i7 activesyncd]$ curl http://[2001:8b0:10b:1:21d:7dff:fe04:dbe2]/ > >> curl: (3) [globbing] error: bad range specification after pos 9 > > > > $ curl http://\\\[2001:8b0:10b:1:21d:7dff:fe04:dbe2\\\]/ > > > "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";> > > Or "curl -g" to disable globbing... It still can't handle link-local addresses: $ curl -g 'http://[fe80::230:48ff:fe41:51d5%br0]/' curl: (6) Could not resolve host: [fe80::230:48ff:fe41:51d5%br0]; Cannot allocate memory Lynx and Elinks make the request OK but includes the '%br0' in the Host: header, which lighttpd (at least) answers with "400 Bad Request". Firefox works (it strips the %br0 from the address before putting it in the Host: header). It would appear that the CLI/terminal web client support for IPv6 link-local addresses is lacking. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
Once upon a time, Camilo Mesias said: > In a sense, part of it isn't under user control. There is a secret in > there, held against the user, and possibly known by the manufacturer > or other third parties. There is also a black box of code that could > do anything. You already have that; it is called System Management Mode. > I'm not really that paranoid but it is worth considering > the worst case, just as a theoretical possibility. What if the device > became standard by virtue of being bundled with every consumer > device... what if it became crucial to system operation somehow... Fedora supporting or not supporting it will have zero impact on that outcome happening or not happening. > Already there are systems that have whitelisted hardware (eg. wireless > cards in netbooks) and the BIOS polices the presence of the right > device. If you make unauthorised modifications to the BIOS, you can > install any compatible wireless card (or WWAN device). BUT if the BIOS > was signed and loaded by a trusted method, this option would not be > available. All of that is pre-kernel, so either can or cannot happen no matter what Fedora does. None of that has any bearing on the technical discussion about whether Fedora should or should not include this functionality in the installer. I think there is some misunderstanding about what the discussion is supposed to be about. The supporting open source code is already in Fedora. The feature request is simply to modify grubby/anaconda to set up the boot entries to include the support by default (or when the hardware is found). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
