Issues with vsftpd on Fedora 12
by Martin Dubuc
LDAP is enabled on my server for authentication. I would like to use vsftpd
on that server, but there is a very big delay during authentication and I am
wondering if this is not an issue with vsftpd software. It seems that even
if I log in as anonymous user, vsftpd tries to access LDAP server. On my
server, I see these error logs during authentication:
Nov 24 15:52:44 localhost vsftpd[25813]: nss_ldap: failed to bind to LDAP
server ldap://10.1.1.5/: Can't contact LDAP server
Nov 24 15:52:44 localhost vsftpd[25813]: nss_ldap: reconnecting to LDAP
server (sleeping 8 seconds)...
After a delay of more than a minute, vsftpd will authorize anonymous user,
but this very long delay is causing me a lot of grief. What is even more
surprising is that I ran tcpdump to see the vsftpd communication to the LDAP
server, but the LDAP server never receives any packets from my Fedora 12
server. It looks like vsftpd thinks it needs to contact the server, but
never does. What is also surprising is that I can ssh to that server and ssh
is configured to use the LDAP server. So, the LDAP server is reachable from
that server.
Not sure how to troubleshoot this issue or if I am the only one with this
problem.
Martin
14 years, 5 months
F12 install stops at screen switch (language select)
by Jos Vos
Hi,
I had the crazy idea to try F12 again on an IBM system (SurePOS 565,
specific Point-of-Sale hardware, with 82915G/GV/910GL), on which RHEL4
was the last RHEL/Fedora version I could install without problems
(see also https://bugzilla.redhat.com/show_bug.cgi?id=339361 for some
comments about RHEL5 on this system).
Well, while graphics didn't work at some point in older releases
(I don't remember which Fedora I tried last, maybe F9 or F10),
now the install stops even earlier, just after:
running /sbin/loader
detecting hardware
waiting for ...
Then the screen blanks (instead of showing the language selection)
and I can't do anything more than CTRL-ALT-DEL.
Any suggestions?
Thanks,
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
14 years, 5 months
Bug in python?
by Christoph Höger
Hi,
while I was investigating an offlineimap bug, the following happened
quite often:
File "/usr/lib64/python2.6/threading.py", line 497, in __bootstrap
self.__bootstrap_inner()
File "/usr/lib64/python2.6/threading.py", line 575, in
__bootstrap_inner
self.__stop()
File "/usr/lib64/python2.6/threading.py", line 586, in __stop
self.__block.notify_all()
File "/usr/lib64/python2.6/threading.py", line 289, in notifyAll
self.notify(len(self.__waiters))
File "/usr/lib64/python2.6/threading.py", line 277, in notify
self._note("%s.notify(): no waiters", self)
File "/usr/lib64/python2.6/threading.py", line 68, in _note
current_thread().name, format)
File "/usr/lib64/python2.6/threading.py", line 808, in currentThread
return _DummyThread()
File "/usr/lib64/python2.6/threading.py", line 788, in __init__
self._Thread__started.set()
File "/usr/lib64/python2.6/threading.py", line 378, in set
self.__cond.notify_all()
File "/usr/lib64/python2.6/threading.py", line 289, in notifyAll
self.notify(len(self.__waiters))
File "/usr/lib64/python2.6/threading.py", line 277, in notify
self._note("%s.notify(): no waiters", self)
File "/usr/lib64/python2.6/threading.py", line 68, in _note
current_thread().name, format)
File "/usr/lib64/python2.6/threading.py", line 808, in currentThread
return _DummyThread()
File "/usr/lib64/python2.6/threading.py", line 788, in __init__
self._Thread__started.set()
File "/usr/lib64/python2.6/threading.py", line 378, in set
self.__cond.notify_all()
File "/usr/lib64/python2.6/threading.py", line 289, in notifyAll
self.notify(len(self.__waiters))
File "/usr/lib64/python2.6/threading.py", line 277, in notify
self._note("%s.notify(): no waiters", self)
File "/usr/lib64/python2.6/threading.py", line 68, in _note
current_thread().name, format)
File "/usr/lib64/python2.6/threading.py", line 808, in currentThread
return _DummyThread()
File "/usr/lib64/python2.6/threading.py", line 788, in __init__
self._Thread__started.set()
File "/usr/lib64/python2.6/threading.py", line 378, in set
self.__cond.notify_all()
File "/usr/lib64/python2.6/threading.py", line 289, in notifyAll
....
Looks to me like calling _DummyThread() every time and then printing a
debug output is a bad idea, right?
14 years, 5 months
heads-up: Oracle db-4.8.24 in rawhide
by Jindrich Novy
Hi,
this is a short announce that there is a new db4 in rawhide for a while
now. Please modify your package accordingly and consider rebuild.
Older db-4.7.25 is now moved to compat-db so no broken dependencies
should occur. If your package uses the /usr/bin/db* utilities please
consider immediate rebuild as these are not present in the compat-db
package.
Thanks,
Jindrich
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
14 years, 5 months
Old/compat package naming
by Lubomir Rintel
Hi,
Alexander pointed out that I was suggesting a wrong name for Saxon 9
package [1]. In fact there's a couple of packages in repositories now
that violate the naming policy [2] in the very same way. Apart from
wondering what does Devrim think about renaming the existing saxon
package, I'm wondering what do others (especially the maintainers of
those other packages) think about renaming their packages?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=532664#c7
[2] https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packag...
The affected packages are these:
antlr 2.7.7-5.fc11
antlr3 3.1.1-7.fc11
automake 1.11-2.fc11
automake17 1.7.9-12
glib 1:1.2.10-32.fc11
glib2 2.20.5-1.fc11
gtk+ 1:1.2.10-68.fc11
gtk2 2.16.6-2.fc11
gtksourceview 1:1.8.5-6.fc11
gtksourceview2 2.6.2-1.fc11
junit 3.8.2-5.4.fc11
junit4 4.5-4.1.fc11
Regards,
Lubo
--
Flash is the Web2.0 version of blink and animated gifs.
-- Stephen Smoogen
14 years, 5 months
PackageKit policy: background and plans
by Owen Taylor
I wanted to provide an update to the list on the current thinking about
the PackageKit policy issue from the perspective of the people working
on the core desktop packages and on the desktop user experience.
There was informal meeting earlier today with Richard Hughes, and
myself, and a couple of people who could provide help with big-picture
Fedora issues like Bill Nottingham and Jesse Keating, to try and figure
out if there were obvious steps to take in the short term.
Obviously there are lots and lots of people who care deeply about this,
and there are discussions that need to continue, but with the delay in
getting packages built, tested, and pushed out, we thought there were
advantages to jump-starting things. If there was something obvious, then
it made sense for the package maintainer (Richard) to just do it.
I'm writing this mail somewhat by default: the people who really matter
are the maintainers of the relevant packages, but Richard has gone to
bed, and David Zeuthen and Matthias Clasen are on vacation this week.
I'll try to reflect what they would say; much of it is certainly my own
personal take on things instead.
- Owen
Where the Fedora 12 policy came from
====================================
In Fedora 9, 10, and 11, the first time a user tried to install a
package from the Fedora repositories, they would be prompted for a root
password, with a checkbox to remember that permission for the future.
(Before Fedora 9, you had to enter the root password every time.)
We weren't really fully happy with this; this was basically asking the
user to construct their own security policy. And not only that, but do
it dialog-by-dialog, permission-by-permission as they tried to set up
their Fedora system and get on with their life.
>From a more general perspective, the end effect of putting up a lot of
dialogs:
+-------------------------------+
| |
| < A complicated explanation > |
| |
| Root password [ ] |
| |
| [ OK ] |
+-------------------------------+
is that you are training users to blindly enter the root password and
hit OK, *not* something that enhances the overall security of the
system.
There is an obvious better way to do this, which is to figure out
what the appropriate roles are for the system: adminstrative users,
non-adminstrative users, etc., and let the person maintaining system
decide who gets what role.
So, David Zeuthen did a major redesign of PolicyKit to move it from
the old "remembered permissions" policy, to a model where users could be
assigned different roles. See:
https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103....
For some more details about how it works.
The idea was that the change in PolicyKit would be accompanied by a
default set of roles, and a nice user interface for assigning users to
roles. Unfortunately, with the constraints of time, it became clear that
this all (and especially the GUI) wasn't going to be there for Fedora
12. So, PackageKit needed a fixed policy for all users. For each action
(install signed packages, install unsigned packages, remove packages,
etc.), it needed to allow, deny, or ask for the root password.
Among the decisions Richard made was allowing all users to install
signed packages from the Fedora repositories. This was clearly the right
behavior for the common case of a single-user system, where the only
user is also the administrator. And it seemed pretty safe: Fedora isn't
supposed to have packages in it that are dangerous to install. (For
example, by policy, all network services must be off by default and not
enabled by simply installing a package.)
The reaction (why that probably wasn't the best choice)
=======================================================
There's obviously been a lot of feedback on this list and in other
forums about this approach. And a lot of good points have brought up.
Probably the most important one is a bit obvious in hindsight: Fedora is
used on a wide variety of systems, and in some of those - like a shared
home system with parents and young children, or like a computer lab
system - there are some users who shouldn't be able to change what is
installed on the system. Even if installing those packages isn't a
security hole.
The other thing that is clear from the discussion is that we didn't do
nearly enough communication about the change. I think was partly because
the changes *weren't* finished. A rewrite of PolicyKit wasn't a feature
in itself; the feature would have been the accounts dialog, which we
didn't do for Fedora 12. But clearly the changes we did do had some
major impacts that needed to be advertised.
And while there are great low-level docs with all the details about
PolicyKit configuration (see polkit(8) for a starting point to the
docs), we didn't have the simple instructions for changing basic system
policy.
Moving forward from here
========================
After talking things through a bit, the consensus was that we need to
take a course that's conservative for Fedora 12. To do something that
is safe for almost all uses of Fedora, if a bit less convenient.
So, what Richard is planning is an update to PackageKit that changes the
policy so that the root password will be required for package
installation. We should have this out in fedora-updates quite soon;
hopefully tomorrow.
Once we get that out, we'll also make sure that there is documentation
available about how you can configure some users to be able to install
software without having to type the root password every time.
In upcoming Fedora releases, we expect to finish both the default set of
policy roles and the user interface components to provide the full
experience that was originally planned.
Executive summary
=================
We'll make an update to the F12 PackageKit, so that the root password is
required to install packages.
14 years, 5 months
PolicyKit and syslog
by Matthew Miller
One of the important features of sudo is its ability to log elevated-access
actions to syslog.
Userhelper similarly logs actions, like so: "userhelper[26491]: running
'/usr/share/system-config-users/system-config-users ' with root privileges
on behalf of 'mattdm'".
PolicyKit serves a similar function, but doesn't seem to log anything.
In fact, the only use of syslog appears to be in polkit-agent-helper-1,
which logs in two possible situations -- when called with the wrong number
of arguments and when stdin is a tty. (Most other things it fprintfs to
stderr.)
I'm not bringing this up to complain -- I just want to make sure that I'm
not missing something (which happens more often than it should; *sigh*). If
I'm not missing something, is this something anyone is working on already or
has existing plans for?
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
14 years, 5 months
Improve the way rpm decides what is newer
by Christian Iseli
Hi folks,
I also got bitten by the "FC11 packages 'newer' than FC12" hickup, and
while going through the yum remove/add maneuver I pondered:
- is there ever a time when, while upgrading from Fedora n to Fedora
n+1 I would expect a package .fcn to be kept instead of getting
the .fcn+1 instance ?
My answer was: no
So I wondered if there would be a simple way to make this happen
regardless of whether a maintainer blunders and gets things slightly
out of sync between the 2 or 3 current Fedora releases.
I did not find a real easy way, but one way which does not seem too hard
to implement would be to introduce one additional tag in a package
named something like VendorRelease. Then, given package A and B we
could implement the "what is newer" comparison as follows:
A.Vendor <=> B.Vendor
|| A.VendorRelease <=> B.VendorRelease
|| A.Epoch <=> B.Epoch
|| A.Version <=> B.Version
|| A.Release <=> B.Release
The VendorRelease, Epoch, Version and Release would be implemented
using the usual, current comparison method. The Vendor comparison
would be taken from a config file, where the admin can decide what is
the preferred Vendor tag.
We might thus be able to solve the old dispute of having repotags by
punting it into the hands of the user. If the user is happy to take
newer versioned packages from some third party repo, he can just define
both Vendors as equal in the config file.
This would also allow getting rid of Epochs from one Fedora release to
the next, since a newer VendorRelease would trump the non-null Epoch.
I'm a bit afraid this might degenerate into another flame fest, but
having slept on it I still think this idea has some merit. So putting
on my asbestos underpants and waiting to see what will come out of
this...
Cheers,
Christian
14 years, 5 months
Re: Fedora 12 x86 DVD images
by Andre Robatino
Jesse Keating wrote:
> Yes, we may rename the Live images to i386. When they were first
> introduced, we had both an i586 and an i686 kernel in Fedora, and the
> Live images were only usable on i686, they had no i586. Now that
> we don't have i586 anymore, we can change the live image name
> to i386. It was too late to do this for F12 at the time
> somebody suggested it.
That makes everything consistent, but creates the same user confusion
for live images that presently exists for install images. Since uname
isn't strictly adhered to even now, why not just change the install
labels to i686 instead?
14 years, 5 months