This bug depends on 90940, which I can't access. Is that deliberately blocked
(security or similar), or was it overlooked in the process of making all this
more open?

It's possible to have this bug depend on some previous bugs that were opened
internally.

The default when installing RHL is the "medium" firewall. The rules it creates
are non-stateful and "suck". :)

I teach 2-3 Red Hat Linux classes a month and you would not believe how much
grief the default rules create.

For this reason, nearly every lab in the official Red Hat Global Learning
Services courseware starts with, "iptables -F" to flush all the default rules.

I nominate Bug 87585 (which has a patch) as a blocker.

The patch updates lokkit to create a stateful ruleset that provides MORE
security than HIGH, yet has NO breakage of connections (RPC or otherwise)
initiated by the host.

Added; issue is that it affects docs, help, screenshots, etc.

I nominate 97845 & 98781 (they're dups).  Not being able to start dial-up
network counts as "suck" to me...

What about bug #101104? mc and/or vi crashing due to a segfault in Gpm_open
kinda sucks as well... And there is a patch, so assuming it is correct this
could be solved quickly.

It's on the other list at the moment.

The libuser RPM is a 'A user and group account administration library'.

It supplies replacements for useradd/mod/del and groupadd/mod/del. It also have
binaries have the same name (and nearly same syntax) just prefixed with an "l".

For example: luseradd, lusermod, luserdel, etc.

The biggest potential is for the libuser commands to provide an easy way to
administer an LDAP Directory that is being used as a NIS replacement. 

However, the currently shipping libuser LDAP backend is broken.

Currently RHL/RHEL has *no* utilities to manage an LDAP server other than
creating LDIF files by hand (yuck!!), let alone specialized utilities for
managing users and groups in an LDAP-as-NIS-replacement server.

I nominate Bug 99435 (contains a patch). The patch fixes up the LDAP backend of
libuser.

Bill will correct me if I'm wrong, but this bug is to track other bug reports,
not to add comments to indicating more problems.  If you have a bug to report
or problem to report, please file a bug report in bugzilla.  If it is considered
a blocker, it will get added as a dependancy here.

Blocker bugs are just trackers, not intended for content addition, at least
thats the way they've always been in the past.  Granted, now that it is open
to the public, people are likely not aware of what the tracker is intended
for.

It's always best to have individual bugs in individual bug reports however,
and increases the chances dramatically that the given issues will be examined,
assigned, prioritized, and tracked.

Hope this helps.

Mike, you're wrong. :)

Seriously, it was posted on rhl-devel-list and rhl-beta-list that people can
nominate bugs for blocker/target status here.

Ok, thanks for the correction Bill.  ;o)  Just trying to keep things in check,
and I didn't know about the email posting.

Thanks again for the clarification.

I think bug 99490 should be here - shipping r-c-httpd that doesn't even start
does not look good.

Please add Bug 104205 because a working patch has been posted.

Cambridge shipped, closing.