Discuss

discuss@lists.centos.org

5 participants
34752 discussions

Problems with mod_auth_ldap module
by Harald Finnås 03 Jun '05

03 Jun '05

Just wondering if anyone's using the apache mod_auth_ldap module with require directives other than "valid-user"? Reason for asking is that no matter what require statement (except valid-user) I try to use, apache logs "unknown require directive". According to the ldap logs it does lookup, and find, the user in question. Any thoughts? Config error or bug? Regards, Harald

1 0

OpenCA rpm package
by User Lists 03 Jun '05

03 Jun '05

Hi all, Somebody knows where I can find an openca rpm package??? Thank you very much. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/

1 0

Is RHEL to CentOS conversion possible?
by Akop Pogosian 03 Jun '05

03 Jun '05

Is it possible to convert an RHEL 3 system into Centos 3 without reinstalling the OS? -- A k o p P o g o s i a n (akopps(a)ls.berkeley.edu) Unix Consultant Letters & Science Computer Resources 461 Birge Hall (phone: 510-643-2989)

3 4

Re: Reboots -- lsof and SIGHUP, a combination to know ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Simon Perreault <nomis80(a)lqt.ca> > Sure, theoretically it would be possible, but how would you restart this one? > [nomis80@poste10-153 ~]$ sudo lsof | grep libc | grep init > init 1 root mem REG 253,0 1521500 999437 /lib/tls/libc-2.3.5.so I need to verify the post-install script for the glibc RPM, but I believe it SIGHUPs the process -- and SIGHUP tells GLibC to reload itself for all new calls from any new process, while leaving the old code available for running processes. Building a tree of service calls and dependencies is the way to figure out what is using what -- even if indirectly. lsof does a fantastic job of this with the right option combinations (I need to look at my command history). Remember, UNIX experience is everything, and that means if I don't know, I get out a test system and throw something like a SIGHUP at it and see what happens. ;-> The lack of using UNIX-like signals in NT is what really makes me dislike NT. Sure, there are lots of UNIX libraries/services that don't always handle every signal -- and many just use SIGHUP as a hard restart. But many of the critical ones do. The majority of even Microsoft's own core libraries are completely ignorant of NT, as they were written for "Chicago." Get to know your UNIX/Linux platform. It's the best way to document procedures that you may need to have in a situation. One I regularly document is how SIGHUP affects different libraries/services. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: Reboots -- LSB 2.1 Core Generic Section 8.5
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > There is nothing wrong with using X11 at runlevel 3. The only thing > that can't be present is a display manager (KDM, XDM, GDM etc). That's _exactly_ what I'm talking about. Run-level 3 starts xdm. Several Linux distros use 2 for multi-user, 3 for multi-user w/X. Run-level 2 as multi-user w/o networking or w/o NFS was introduced by Red Hat, and any Fedora-based (or RHL-based) distro uses it. > If it is, it is wrong, and doesn't comply with the unix standard (don't > remember exactly which, but I studied it when working for Conectiva). First off, it's not "wrong." Many distros established many different standards well before any standardization efforts. Even Linus admits that he based many things off of SunOS 4.1 (retroactively Solaris 1) and Solaris 2, and Solaris uses 2-3. [ Remember, Solaris was the original GNU platform. ] So in that regard, Debian is actually like Solaris in its use of 2-3, instead of Fedora-based 3-5. Secondly, you are referring to Linux Standards Base (LSB). Specifically, Section 8.5 in the General Section of the latest revision: http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-gener… And even this latest version states: "However, it is not required that LSB-compliant run-time environments use these run levels; the distribution-provided install_initd script may map the run levels specified below to whatever distribution-specified run levels are most appropriate." It should also be noted that not even Fedora Core's init scripts are fully LSB compliant, and Debian and SuSE do far better in many areas. LSB even declares RPM as the package standard. But at the same time, one might remember why LSB came into existance -- to try to get standards across largely FC/RHL forks and other RPM distros. As much as it attempts to be platform agnostic, some of its standards are heavily defaulting to RPM ones. > The standard is there. If a distro chooses not to follow it, > you can be very sure it will have acceptance problems. Not nit-pick, but your statement was _exactly_: "Also, run-levels are standarized, and should be the same on all unix-like platforms." Not only is there _no_ standard for System-V platforms, but pretty much LSB says even Linux distros can do what they want. There is _no_ "run-level standard" for "unix-like platforms." > When I have time later today (or tomorrow), I'll give out the > standard I'm mentoning and will give you a proper reference. > Sorry I can't provide it from the top of my head. LSB 2.1 Core Generic Section 8.5. Again, URL: http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-gener… Just to summarize, this thread was _not_ to "prove you wrong." It was just a reminder that not only do Linux systems vary wildly, but "UNIX-like" systems do as well and you should be careful with assumptions. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 20

Re: Reboots -- Short Answer
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Prasad Pillarisetti <prasad.pillarisetti(a)gmail.com> > ***Do you perform downtimes just for the purpose of rebooting the systems? > ***Is there a recommended interval Linux system should be rebooted? Okay, here's my short answer: Regardless of OS, you should _always_ reserve dates/times for preventive maintenance on a regular basis. But I agree with most others, unless it is a kernel upgrade or GLibC change, there's no absolutely need to reboot. Not even during preventive maintanence should you feel compelled. -- Bryan J. Smith mailto:b.j.smith@ieee.org

4 6

rhel3 < centos3 updates
by Stephen M. Gava 03 Jun '05

03 Jun '05

Hi all, I've been approached by someone who has an installation of rhel ES 3 (taroon update 2) to see whether I can take over doing security and other updates for them (no current rhn subscription). What I want to know is, with a suitable yum setup can I use a centos3 repository to apply updates to this box? If so, should I source updates from centos 3.5? Does the whole box need to become a centos3 box to do this? They'd really like to disturb the existing box (I agree) as little as possible since it's a stable production server, and mainly just want important security related updates etc. done. Ok, tia for any answers, Stephen. -- Stephen M. Gava <smig(a)users.sourceforge.net>

3 4

Re: Vote For CentOS :) -- at this point, call the FSF ...
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Can you get the product without being bound by the restrictions? > That is, can one user purchase one and resell copies without the SLA > or with their own? Not with the trademark, that is mis-appropriation. If you want to complain about Red Hat doing this, then you'll want to complain about a number of distributors well before Red Hat who are far worse. > The GPL covers anything that can be considered a derivative work under > copyright law. That certainly includes binaries. Now you're mixing things. The GPL does _not_ address binaries, just what is required -- availability of source, and no restrictions on that source for things that are required for that source to work -- _regardless_ of what is redistributed. It also states that you can't use GPL source with someone non-GPL that requires it to function. Trademarks do not. The software functions the same regardless whether or not you have the trademark. > No one is obligated to provide them, but they cannot prohibit copying > or redistribution as long as the requirement to include or offer source is > met. No one can prohibit restricting the _source_. Again, you are mixing things. I can restrict whatever I want on the binaries, as long as I'm abiding by the other terms of the GPL on the source. That means I don't redistribute anything in any form, unless the source for that is freely available in a way that is unrestricted that the software works the same. SuSE, Dan's Guardian and other distros/software go farther in not even making source packages available. Red Hat at least dumps out _all_ SRPMs, even the overwhelming majority they could point to Fedora for. > No, it covers all derivative works. No, copyright law does. If a copyright holder explicitly states that he/she will not allow trademarks to be bundled with the software, or any installer or other "helper" software, then he/she has the right to do that. But the GPL itself does _not_. > Otherwise it could not prohibit distribution of something that must be > linked to a proprietary dynamic library to function. But trademarks are _not_ required for the software to function exactly the same. That's the difference! Again, you're mixing things. > Typically the FSF has claimed that anything linked into a binary > becomes part of the derivative work. [ The BS watches Les drop off the deep end ;-] > I don't particularly agree with it You don't particularly seem interested in realizing that Red Hat is the _least_ of our problems among commercial companies. And you don't seem to be interested in Trademark Law, and the whole concepts of why it exists. Red Hat's "goodwill" severely crippled their ability to deal with some companies who have no problem with trashing their name. I don't think you realize that Microsoft could have flooded the market with an ultra-crappy "Red Hat(R) Linux" that would have destroyed mindshare overnight. Sun was basically on their way to doing it too, which pissed a lot of us off. Because of Sun and others, Red Hat had to vehemetly defend their trademark to the anal power, and projects like CentOS are stuck with dealing with that as a result. Red Hat is the _only_ major commercial Linux entity that allowed redistribution of its trademark on a scale large enough that it could have been declared "public domain" by the USPTO. Red Hat lives with that now. *NO* other commercial vendor will attempt it in the future either. [ The only exception seems to be SuSE(R), which Novell seems to be turning into a "Fedora-like" trademark. ] > - I'm just reading what it says, and 'no additional restrictions' > seems pretty clear. Take "Red Hat(R)" out of the GPL software and it works _exactly_ the same. If you really have a bug up your ass about this, ask FSF lawyers. ;-> Red Hat can only say they've cleared it with the FSF so many times before people who don't want to believe will _never_ believe (like yourself). The maintainer of Dan's Guardian regularly gets ignorant pukes who complain he is "violating" the GPL by not making the source available on his web site. Same deal, he's got things cleared with the FSF and Stallman, but people want to assume things. The GPL is _not_ about "free" -- it's about "freedom." The "freedom" to modify source code and keep software alive, well after the copyright holders might be dead or don't care. It doesn't give you the right to mis-appropriate trademarks. And unlike patents, trademarks are _not_ required for the software to function legitimately and exactly. > If someone adds their trademark to something that becomes a > derivative work of something carrying the GPL, they should either > not be able to distribute at all, or they have to allow redistribution. If the GPL 3.0 says this, then pretty much not only will _all_ commercial distributions die, but pretty much all support avenues for Linux. I don't think you realize the precedent you're asking for. > Things that aren't embedded in a GPL work would be different, You _can_ "bundle" anything with GPL that it doesn't require. > like artwork that happens to be on the same disk and there is no > requirement to make it easy to separate the 'merely aggregated' > parts, though. What do you mean by "embedded"? RPM is merely just a USTAR 5KB block size (cpio System-V) archive. Even an ISO9660 "Yellow Book" track (data CD) can be considered an "archive." Do you _really_ want to open up that "subjective" door? At this point, ask the FSF. I think you're just going to argue this until you get the answer you like. Good luck with the FSF. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] Vote For CentOS :)
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Of course. What does an SLA have to do with restricting copying or > redistribution? Because you're paying for services, not a product. > What kind of restriction would be excluded by the GPL if not ones that > restrict copying, installing on additional machines, or redistribution? Public redistribution of the _binaries_ is prohibited because of the trademarks. There is _no_ term in the GPL that mandates that anyone provide you with binaries or otherwise packaged software that is "ready-to-use." This is the GPL. At the same time, as long as the additives are not required for the software to function, Red Hat, SuSE, Novell, Mandrake, etc... are free to bundle whatever art, trademarks, etc... with the software, even the source code. The GPL still only guarantees you the right to _source_ code redistribution without restriction. If you want to play the trademark card, then you're going _outlaw_ pretty much _every_ major commercial company from producing GPL software. And Red Hat is the least of our concerns. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: Reboots -- everything's a file
by Bryan J. Smith <b.j.smith＠ieee.org> 03 Jun '05

03 Jun '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > Actually, there is another neat trick for rpm based systems. > You see, rpm, prior to removing anything, will rename that to ${NAME}.OLD. > So, libc.so.6 becomes libc.so.6.OLD, and then removed. > As we all know, if that library is currently open by any running process, > it won't be imediately removed (even tho you can't see it with a 'ls'). > The trick is pretty simple: lsof | grep OLD > That, of course, only aplies if you are doing everything using RPM > (yum, redhat-update, apt-get). That's because open file handles work in inode number, not filename. So you can rename things out-of-the-way for existing file handles, while creating a new file that will be opened for any new ones. Devices, processes, etc... in UNIX pretty much have the same logic as files. Which is why I love UNIX -- everything acts like a file, with similar meta-data, etc... -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss