Please fix longstanding problem with authconfig/pam_ldap config
by Charles Lopes
I'd like to attract attention to a problem described in bugs #55193,
#63631, #77575, #86606, #103461 and #118239.
If a system is configured to use LDAP for authentification with
authconfig, logins to local accounts (root for example) will always fail
if the LDAP server is unreachable. A possible fix described in bug
118239 has a working pam config for such cases.
Is there any security concern or backward compatibility issue with the
proposed configuration?
Is there something that prevent authconfig from being changed to
generate such a configuration?
This could possibly affect other network authentification mechanism
(kerberos, smb), althought I can't verify it. Also that could possibly
fix bug #6371 as well.
20 years
Fedora Tracker: Part Deux
by Brad Smith
A new and (hopefully) improved version of Fedora Tracker is now up at:
http://academy.phpwebhosting.com/cgi-bin/tracker/tracker.py
New features of interest:
* Search results are sorted by repository type (core, extras, tp, etc)
* Package search defaults to simplified interface
* Source packages are filtered out by default to cut down on search
results.
Among the other features I hope to add based on suggestions I've gotten
here is the ability to have search results display "condensed". That is,
just the name, description and a link to view details on all instances
of this package. I think that will make search results much more
readable but because it adds an extra pageload between initiating a
search and actually getting the package I'm reticent to make it the
default. It will probably be a checkbox option on the advanced search
page.
I'll also add a "news" page or something so as to stop bugging you folks
with updates =:). Since these most recent changes are the result of
feedback from this list, though, I thought it appropriate to post about
here.
Comments?
--Brad
20 years
Re: Fedora Tracker: Part Deux
by Jef Spaleta
Matt H wrote:
> You mentioned that this project is not a part of Red Hat or the
> Fedora Steering Committee. However, as this becomes more well-known >
and widely used, will you consider proposing it become part of The >
Fedora Project directly; much like The Fedora Docs Project and
> similar? Or at least host it at fedora.redhat.com?
This is going to be very very tough to do I think. For the same reasons
the tracker might best be hosted outside the US, the tracker might not
be able to be incorporated into the official project as hosted and
managed by Red Hat. Right now, I'm working under the assumption that
incorporating anything similar to this tracker idea into the main fedora
project site is not something Red Hat can do without taking on a finite
amount of legal risk, due to the DMCA, because of links to 3rd party
repositories containing patent and copyright encumbered software that is
not legally redistributable in the US. It's not even clear the official
site can even link to a tracker due to the DMCA issues without some
risk.
Now we can all grumble about how crappy the DMCA is..and make noises
about fighting it somehow. It's a crappy situation, and as much as I
want to see functionality like this rolled into the red hat hosted
fedora site, I'm not going to demand that Red Hat deliberately and
knowingly break a US law. If Red Hat or any US individual for that
matter wants to commit an act of civil disobedience by breaking a law
they don't agree with its their choice to do so, but its not something
anyone can demand another person or entity to do. If US citizens on
this list want to take on the legal liability and provide mirrors of the
tracker, that's their decision, and would make for an interesting
example of organized protest but I'm not going to demand that anyone
knowingly break a law.
If I were going to demand anything, i would demand that 3rd party
repository creators make at least a token effort split the non-US and US
redistributable packages into separate repositories. It seems completely
irrational to me, to be providing additional packages for a US based
Fedora Core, and not making an effort to work around the legal problems
that Fedora Core has to live with respect to the DMCA. I don't see ANY
search functionality being rolled into the official fedora project site
that includes searching for packages that run afoul of US patent or
copyright laws. If the official site does gain a package search feature,
I highly doubt it will return any information about packages that can't
be redistributed in the US. And at this point, that means only a few 3rd
party repos could be indexed in such an official way because they do not
make an effort to split US and non-US distributable package sets into
separate trees.
So moving forward there is a choice to be made by the 3rd party
repository community. Do they want to make it easier for the official
project to link to them, by taking steps to work inside the
non-technical limitations such as the DMCA that the official project
must abide by. Or do they want to be completely free to package what
they want how they want, paying no heed to the legal constraints FC must
live under and thus having to always stay one Google search away from
users finding any of your packages. There are pros and cons for both
sides of that decision. And more importantly what the widely used
end-user community tools will look like will depend on what the
consensus is in the 3rd party repo community. There's really no point
in trying to build something like this tracker into the main site, if
most of the popular 3rd party repos can't be indexed because of the
DMCA.
20 years
Selinux and named
by Ivan Gyurdiev
Named complains: capset failed whether in enforcing mode or not.
Online documentation suggests ./configure --disable-linux-caps,
but I'd like to keep my bind rpm.
What could be the problem?
20 years
RE: Selinux and named
by Erik LaBianca
> -----Original Message-----
> From: fedora-devel-list-bounces(a)redhat.com [mailto:fedora-devel-list-
> bounces(a)redhat.com] On Behalf Of Ivan Gyurdiev
> Sent: Monday, March 29, 2004 6:35 PM
> To: fedora-devel-list(a)redhat.com
> Subject: Selinux and named
>
> Named complains: capset failed whether in enforcing mode or not.
>
> Online documentation suggests ./configure --disable-linux-caps,
> but I'd like to keep my bind rpm.
>
> What could be the problem?
>
Bind automatically tries to escalate its priority, and something
(selinux?) is denying it. I'd like to suggest that the officially
distributed bind be built with --disable-linux-caps. Programs should not
automatically attempt to escalate themselves IMHO. If the process
priority needs to be changed, it should be done in the init script.
This change would also allow fedora's bind to work under a vserver
without modifications, which would certainly make a few of us happy.
You could probably fix this problem by changing the selinux policy, but
I can't help you much there. With vserver, you would need to allow
CAP_SYS_RESOURCE, and I'm guessing the solution under selinux would be
close to that.
--erik
20 years
Dealing with DMCA issues in Tracker
by Brad Smith
It has been pointed out to me that one problem Tracker may run into is
legal issues with linking directly to the RPMs at livna.org. I've been
thinking about ways to nip potential legal issues in the bud and am
looking at two possible solutions.
Option 1: It would be relatively easy to have the "download" links for
packages from Extras-NonUs repositories point to a page explaining that
because Tracker is hosted in the US, it cannot provide links to the
software in question. It can then include instructions on adding the
relevant repo to the user's apt/yum sources and installing the package
that way.
Option 2: Some have suggested hosting Tracker outside of the US. One
problem I see with this is the fact that Tracker relies heavily on
optimizations in mysql 4.x which, because of licensing issues, is still
not easily available on Fedora. In order for Tracker to run well, the
hosting system would have to install Mysql 4.x. Not a big deal, but it
does entail extra work for the system's admin. I don't know if it's
appropriate to ask for such things on this list, but let's just say that
in order for option 2 to to be viable I would first need some
international volunteers =;).
I'm leaning toward option 1 for now, if only to save myself the trouble
of migrating everything. Opinions and legal details (my knowledge of the
issue basically boils down to "DMCA BAD! ROAR!") are, as always,
appreciated.
--Brad
20 years
inittscripts
by Josep Puigdemont
The following string:
/etc/rc.d/rc.sysinit:246
#, c-format
msgid "Press Y within %d seconds to force file system integrity
check..."
Doesn't seem to be "localizable", as the script always expects "y":
if /sbin/getkey -c $AUTOFSCK_TIMEOUT -m $"Press Y within %d seconds to
force file system integrity check..." y ; then
AUTOFSCK_OPT=-f
fi
Regards,
Josep
P.S.: I have the impression that I shouldn't "submit" this "bug" here,
is it ok, or should I directly go to bugzilla? Thanks
20 years
Fedora Core 2 Test 2 available for x86 and x86-64
by Bill Nottingham
One bug, two bugs, tar bugs, su bugs,
grep bugs, mew bugs, old bugs, new bugs.
This bug has a little hack,
This bug has a broken stack.
Say! What a lot of bugs to track.
Yes, some are in tar, and some in su.
Some are old. And some are new.
Some in sed, and some in jed.
And some are even in parted.
Why are they in parted, jed and sed?
I do not know. Bugs should be dead!
Some in jpeg, and some in TIFF
This TIFF one has an attached diff.
>From there to here, from here to there
Test release bugs are everywhere.
Fedora Core test 2 is available for
x86 and x86-64
It should not be installed where production is hot;
use it only for test, as we say quite a lot.
If you install with the default
SELinux will be the result
SELinux is a form of MAC
For more answers, check the FAQ [*]
By explicitly stating what apps can use
Unwanted accesses it will refuse
[*] http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/
So please test test2 in this mode;
and please test it with your code.
Plus it comes with a new GNOME;
can you test that in your home?
Also X.org is new,
replacing XFree, test it too.
And 3.2.1 of KDE
We need to test, test, test, you see!
So we will test it on our box.
And we will even test out sox.
And we will test it in our house.
And we will test it with our mouse.
And we will test it here and there.
Say! We will test it ANYWHERE!
Problems with Fedora Core 2 test 2 should be reported via
bugzilla, at:
http://bugzilla.redhat.com/bugzilla/
Please report bugs against 'Fedora Core', release 'test2'.
For more information on just what the Fedora Project and
Fedora Core is, please see:
http://fedora.redhat.com/
For discussion of Fedora Core 2, Test 2, send mail to:
fedora-test-list(a)redhat.com
with
subscribe
in the subject line. You can leave the body empty. Or see:
https://listman.redhat.com/mailman/listinfo/fedora-test-list/
As always, you can get Fedora Core test releases at redhat.com, specifically:
http://download.fedora.redhat.com/pub/fedora/linux/core/test/1.91/
and at the following mirrors:
* North America
* USA East
* http://mirror.linux.duke.edu/pub/fedora/linux/core/test/1.91/
* ftp://mirror.linux.duke.edu/pub/fedora/linux/core/test/1.91/
* rsync://mirror.linux.duke.edu/fedora-linux-core/test/1.91/
* ftp://ftp.cse.buffalo.edu/pub/fedora/linux/core/test/1.91/
* http://mirror.eas.muohio.edu/fedora/linux/core/test/1.91/
* ftp://mirror.eas.muohio.edu/pub/fedora/linux/core/test/1.91/
* http://redhat.secsup.org/fedora/core/test/1.91/
* ftp://redhat.secsup.org/pub/linux/redhat/fedora/core/test/1.91/
* ftp://mirror.clarkson.edu/pub/distributions/fedora/test/1.91/
* http://mirror.clarkson.edu/pub/distributions/fedora/test/1.91/
* ftp://ftp.gtlib.cc.gatech.edu/pub/fedora.redhat/linux/core/test/1.91/
* http://www.gtlib.cc.gatech/edu/pub/fedora.redhat/linux/core/test/1.91/
* rsync://rsync.gtlib.cc.gatech.edu/fedora-linux-core/test/1.91/
* http://mirror.hiwaay.net/redhat/fedora/linux/core/test/1.91/
* ftp://mirror.hiwaay.net/redhat/fedora/linux/core/test/1.91/
* rsync://mirror.hiwaay.net/fedora-linux-core/test/1.91
* USA West
* ftp://limestone.uoregon.edu/fedora/test/1.91/
* ftp://linux.stanford.edu/pub/mirrors/fedora/linux/core/test/1.91/
* Canada
* ftp://less.cogeco.net/pub/fedora/linux/core/test/1.91/
* http://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/core/test/1.91/
* ftp://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/core/test/1.91/
* ftp://ftp.muug.mb.ca/pub/fedora/linux/core/test/1.91/
* http://ftp.muug.mb.ca/pub/fedora/linux/core/test/1.91/
* rsync://ftp.muug.mb.ca/pub/fedora/linux/core/test/1.91/
* South America
* Chile
* ftp://ftp.tecnoera.com/Linux/fedora/test/1.91/
* Europe
* Czech Republic
* http://sunsite.mff.cuni.cz/pub/fedora/test/1.91/
* ftp://sunsite.mff.cuni.cz/pub/fedora/test/1.91/
* rsync://sunsite.mff.cuni.cz/fedora/fedora/test/1.91/
* ftp://ftp.fi.muni.cz/pub/linux/fedora/linux/core/test/1.91/
* rsync://ftp.fi.muni.cz/pub/linux/fedora/linux/core/test/1.91/
* Denmark
* ftp://klid.dk/pub/fedora/core/test/1.91/
* Finland
* ftp://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/test/...
* ftp://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/...
* Germany
* http://wftp.tu-chemnitz.de/pub/linux/fedora-core/test/1.91/
* ftp://ftp.tu-chemnitz.de/pub/linux/fedora-core/test/1.91/
* ftp://ftp.informatik.uni-frankfurt.de/pub/linux/Mirror/ftp.redhat.com/fed...
* ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/core/...
* Netherlands
* ftp://ftp.quicknet.nl/pub/Linux/download.fedora.redhat.com/test/1.91/
* ftp://alviss.et.tudelft.nl/pub/fedora/core/test/1.91/
* Norway
* ftp://ftp.uninett.no/pub/linux/Fedora/core/test/1.91/
* Portugal
* ftp://tux.cprm.net/pub/ftp.redhat.com/fedora/linux/core/test/1.91/
* Poland
* ftp://ftp.wsisiz.edu.pl/mirror/download.fedora.redhat.com/test/1.91/
* Romania
* http://ftp.lug.ro/fedora/linux/core/test/1.91/
* ftp://ftp.lug.ro/fedora/linux/core/test/1.91/
More mirrors will come online in the near future; check:
http://fedora.redhat.com/download/mirrors.html
for a list of mirrors that carry Fedora Core.
One additional feature provided by the Linux community is the
availability of Fedora Core releases via BitTorrent.
http://torrent.dulug.duke.edu/FC2-test2-binary-i386.torrent
http://torrent.dulug.duke.edu/FC2-test2-binary-x86_64.torrent
See http://torrent.dulug.duke.edu/ for other forms, including
SRPMS and the DVD iso.
RPMS for Red Hat Linux 7.3 through 9 and Fedora Core 1 of BitTorrent are
available from:
http://torrent.dulug.duke.edu/btrpms/
Usage is simple:
btdownloadcurses.py --url http://URL.torrent
Allow incoming TCP 6881 - 6889 to join the torrent swarm.
20 years
