Updated Packages:
NetworkManager-0.7.0-0.cvs20060521 ---------------------------------- * Sun May 21 2006 Dan Williams dcbw@redhat.com - 0.7.0-0.cvs20050621 - Update to latest CVS - Drop special-case-madwifi.patch, since WEXT code is in madwifi-ng trunk now
* Fri May 19 2006 Bill Nottingham notting@redhat.com - 0.6.2-3.fc6 - use the same 0.6.2 tarball as FC5, so we have the same VPN interface (did he fire ten args, or only nine?)
* Thu Apr 27 2006 Jeremy Katz katzj@redhat.com - 0.6.2-2.fc6 - use the hal device type instead of poking via ioctl so that wireless devices are properly detected even if the kill switch has been used
glibc-2.4.90-9 -------------- * Sun May 21 2006 Jakub Jelinek jakub@redhat.com 2.4.90-9 - update from CVS - big NIS+ changes
* Fri May 19 2006 Jakub Jelinek jakub@redhat.com 2.4.90-8 - update from CVS - fix nss_compat when SETENT_BATCH_READ=TRUE is in /etc/default/nss - fix RFC3484 precedence table for site-local and ULA addresses (#188364) - fix a sunrpc memory leak
glibc-kernheaders-3.0-35 ------------------------ * Sun May 21 2006 David Woodhouse dwmw2@redhat.com 3.0-35 - Fix asm-x86_64/mtrr.h to not attempt to include <linux/compat.h>
libraw1394-1.2.1-1.fc5 ---------------------- * Thu Apr 13 2006 Jarod Wilson jwilson@redhat.com - 1.2.1-1.fc5 - 1.2.1
linuxwacom-0:0.7.4_1-2 ---------------------- * Sun May 21 2006 Peter Jones pjones@redhat.com 0:0.7.4_1-2 - fix the sysfs test equality syntax in the udev rule
udev-092-2 ---------- * Sun May 21 2006 Peter Jones pjones@redhat.com - 092-2 - Fix typo in pam-console rule
Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution - 2.7.2.1-1.ppc64 requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 gnome-power-manager - 2.15.2-1.ppc64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.ppc64 requires libnotify.so.0()(64bit) hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.9.4.1-2.ppc64 requires libnotify.so.0()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5
Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390 requires libnotify.so.0 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 gnome-power-manager - 2.15.2-1.s390 requires libnotify.so.0 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5
Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.i386 requires libnotify.so.0 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-power-manager - 2.15.2-1.i386 requires libnotify.so.0 gnome-volume-manager - 1.5.15-1.1.i386 requires libnotify.so.0 rhythmbox - 0.9.4.1-2.i386 requires libnotify.so.0
Broken deps for ppc ---------------------------------------------------------- evolution - 2.7.2.1-1.ppc requires libnotify.so.0 gnome-power-manager - 2.15.2-1.ppc requires libnotify.so.0 gnome-volume-manager - 1.5.15-1.1.ppc requires libnotify.so.0 rhythmbox - 0.9.4.1-2.ppc requires libnotify.so.0
Broken deps for ia64 ---------------------------------------------------------- evolution - 2.7.2.1-1.ia64 requires libnotify.so.0()(64bit) gnome-power-manager - 2.15.2-1.ia64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.ia64 requires libnotify.so.0()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.4.1-2.ia64 requires libnotify.so.0()(64bit)
Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.x86_64 requires libnotify.so.0()(64bit) gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-power-manager - 2.15.2-1.x86_64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.x86_64 requires libnotify.so.0()(64bit) rhythmbox - 0.9.4.1-2.x86_64 requires libnotify.so.0()(64bit)
Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390x requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 gnome-power-manager - 2.15.2-1.s390x requires libnotify.so.0()(64bit) hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5
Build System wrote:
glibc-2.4.90-9
- Sun May 21 2006 Jakub Jelinek jakub@redhat.com 2.4.90-9
- update from CVS
- big NIS+ changes
Maybe I'm just ignorant about the field, but is any RedHat/Fedora user still using NIS+ instead of LDAP in corporate environments?
I wonder whether NIS, NIS+, Hesiod and DB support in glibc could be dropped altogether to reduce the size of Core and simplify dependencies.
Maybe those NSS modules could just be splitted out and moved to Extras?
On Wed, 2006-05-24 at 09:41 +0200, Bernardo Innocenti wrote:
Build System wrote:
glibc-2.4.90-9
- Sun May 21 2006 Jakub Jelinek jakub@redhat.com 2.4.90-9
- update from CVS
- big NIS+ changes
Maybe I'm just ignorant about the field, but is any RedHat/Fedora user still using NIS+ instead of LDAP in corporate environments?
I wonder whether NIS, NIS+, Hesiod and DB support in glibc could be dropped altogether to reduce the size of Core and simplify dependencies.
dropping nis would be a serious problem for a lot of folks, including myself.
For simple multi-machine nss nis is still, by far, the simplest to setup and maintain.
-sv
seth vidal wrote:
For simple multi-machine nss nis is still, by far, the simplest to setup and maintain.
LDAP sure isn't an easy beast to configure and run, expecially if you need TLS and replication.
But this is largely a distribution issue: the default configuration in Fedora does not come close to what would be needed to setup an LDAP authentication server. And there are no system-config-* tools for newbies to use. I've had similar experience with other Linux distributions.
Linux is now the only OS that doesn't provide out of the box authentication and directory services for corporate environments. Windows got there six years ago with ActiveDirectory and MacOSX does it beautifully with NetInfo and its nice OpenLDAP integration.
As an administrator, I'm particularly embarassed to show my customers the tools I use to run their UNIX accounts and Samba domain controller.
On Wed, 2006-05-24 at 10:13 +0200, Bernardo Innocenti wrote:
seth vidal wrote:
For simple multi-machine nss nis is still, by far, the simplest to setup and maintain.
LDAP sure isn't an easy beast to configure and run, expecially if you need TLS and replication.
But this is largely a distribution issue: the default configuration in Fedora does not come close to what would be needed to setup an LDAP authentication server. And there are no system-config-* tools for newbies to use. I've had similar experience with other Linux distributions.
Linux is now the only OS that doesn't provide out of the box authentication and directory services for corporate environments. Windows got there six years ago with ActiveDirectory and MacOSX does it beautifully with NetInfo and its nice OpenLDAP integration.
As an administrator, I'm particularly embarassed to show my customers the tools I use to run their UNIX accounts and Samba domain controller.
You might get involved and help write such tools. That would replace embarrassment with pride.
Rahul
2006/5/24, Rahul Sundaram sundaram@fedoraproject.org:
On Wed, 2006-05-24 at 10:13 +0200, Bernardo Innocenti wrote:
seth vidal wrote:
For simple multi-machine nss nis is still, by far, the simplest to setup and maintain.
LDAP sure isn't an easy beast to configure and run, expecially if you need TLS and replication.
But this is largely a distribution issue: the default configuration in Fedora does not come close to what would be needed to setup an LDAP authentication server. And there are no system-config-* tools for newbies to use. I've had similar experience with other Linux distributions.
Linux is now the only OS that doesn't provide out of the box authentication and directory services for corporate environments. Windows got there six years ago with ActiveDirectory and MacOSX does it beautifully with NetInfo and its nice OpenLDAP integration.
As an administrator, I'm particularly embarassed to show my customers the tools I use to run their UNIX accounts and Samba domain controller.
You might get involved and help write such tools. That would replace embarrassment with pride.
Rahul
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
i second that a tool that makes it "intuitive" to setup ldap authentication and later maybe even "single sign on" possible would make a nice enhancement for fedora.
regards, Rudolf Kastl
p.s. id maybe help with python hacking there once a project is set up.
Rahul Sundaram wrote:
As an administrator, I'm particularly embarassed to show my customers the tools I use to run their UNIX accounts and Samba domain controller.
You might get involved and help write such tools. That would replace embarrassment with pride.
Unfortunately, it's not like you can write a couple of new applications and you're done. It would take some commitment by a distribution such as Fedora to bring the small bits together.
Most tools are there already, but not designed or tested to work well together. And it's because very few people go through the pain of setting up an LDAP-based LAN.
For example, Samba uses its own user database by default and it takes lots of perl glue (the smbldap-tools) to get it to fetch domain users from LDAP. You also need to add custom schemas and fiddle with obscure configuration parameters until it works. Maybe Samba4 will improve the situation.
Creating users in LDAP is hard. The usual tools such as useradd and system-config-users should be teached how to do it. I still couldn't figure out how to change the posixAccount password in LDAP without using smbpasswd.
Viewing and editing the LDAP database is hard. The best tool I've found is ldapvi, which is very low level and isn't even in Extras. There are lots of Java GUI tools which I'd avoid if I could and a few web-based ones with the usual slow user interface. The best one seems to be phpLdapAdmin. It's in Extras, but you have to fiddle a lot with the configuration before you can authenticate into your LDAP server.
On the client side, system-config-authentication already does 90% of the work, but fails to do (or suggest) the steps required to get TLS to work. Without TLS, your passwords wil fly over the wire in clear.
Unfortunately, it's not like you can write a couple of new applications and you're done. It would take some commitment by a distribution such as Fedora to bring the small bits together.
Right now, it requires a lot of integration work, but works pretty well.
Most tools are there already, but not designed or tested to work well together. And it's because very few people go through the pain of setting up an LDAP-based LAN.
I have set up some LDAP-based LAN's and I think that, although not straightforward as installing Linux and clicking Next, Next, Next, i'ts not as difficult as it could seem.
Creating users in LDAP is hard. The usual tools such as useradd and system-config-users should be teached how to do it. I still couldn't figure out how to change the posixAccount password in LDAP without using smbpasswd.
You can use "libuser", which supports several backends, being LDAP on of then. I'm using luseradd/lusermod/luserdel/lgroupadd/lgroupdel/lgroupmod from libuser to manage my LDAP users and its work very well.
Felipe Alfaro Solana wrote:
Most tools are there already, but not designed or tested to work well together. And it's because very few people go through the pain of setting up an LDAP-based LAN.
I have set up some LDAP-based LAN's and I think that, although not straightforward as installing Linux and clicking Next, Next, Next, i'ts not as difficult as it could seem.
Really? Have you imported and existing userbase? Did you enable TLS? Replication? Kerberos? SASL?
After months of occasional research and fiddling, I'm still unable to do effective Single Sign On for the intranet services (IMAP, Apache, NFS...) with any of the clients (NT, Linux, OSX).
You can use "libuser", which supports several backends, being LDAP on of then. I'm using luseradd/lusermod/luserdel/lgroupadd/lgroupdel/lgroupmod from libuser to manage my LDAP users and its work very well.
Looks nice!
I'm currently unable to make any changes because of this:
Error initializing libuser: could not negotiate TLS with LDAP server.
And it's weird, because I've configured my ldap.conf to use the ldapi socket locally and no TLS is needed for the other tools I use.
On Thu, 2006-05-25 at 08:10 +0200, Bernardo Innocenti wrote:
Viewing and editing the LDAP database is hard. The best tool I've found is ldapvi, which is very low level and isn't even in Extras. There are lots of Java GUI tools which I'd avoid if I could and a few web-based ones with the usual slow user interface. The best one seems to be phpLdapAdmin. It's in Extras, but you have to fiddle a lot with the configuration before you can authenticate into your LDAP server.
lat (LDAP Administration Tool) is quite nice and is awaiting a maintainer in Extras: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177580
Paul.
On Thu, 25 May 2006, Paul Howarth wrote:
On Thu, 2006-05-25 at 08:10 +0200, Bernardo Innocenti wrote:
Viewing and editing the LDAP database is hard. The best tool I've found is ldapvi, which is very low level and isn't even in Extras. There are lots of Java GUI tools which I'd avoid if I could and a few web-based ones with the usual slow user interface. The best one seems to be phpLdapAdmin. It's in Extras, but you have to fiddle a lot with the configuration before you can authenticate into your LDAP server.
lat (LDAP Administration Tool) is quite nice and is awaiting a maintainer in Extras: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177580
Along these lines has anyone here setup Fedora Directory server in place of openldap??
If so I am curious what if any additional problems were encountered.
I have read the howto on the FDS wiki and it looks pretty streight forward but...
Regards,
Tom Diehl tdiehl@rogueind.com Spamtrap address mtd123@rogueind.com
Along these lines has anyone here setup Fedora Directory server in place of openldap??
Me
If so I am curious what if any additional problems were encountered.
Not much: it works pretty well. Fedora Directory Server 1.0.1 had problems with the pasword change extended operation, but Richard fixed the problem and the fix is already in version 1.0.2.
Paul Howarth wrote:
lat (LDAP Administration Tool) is quite nice and is awaiting a maintainer in Extras: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177580
That's indeed the best GUI tool I've seen so far for managing LDAP.
On Thu, 2006-05-25 at 08:10 +0200, Bernardo Innocenti wrote:
Rahul Sundaram wrote:
As an administrator, I'm particularly embarassed to show my customers the tools I use to run their UNIX accounts and Samba domain controller.
You might get involved and help write such tools. That would replace embarrassment with pride.
Unfortunately, it's not like you can write a couple of new applications and you're done. It would take some commitment by a distribution such as Fedora to bring the small bits together.
A distribution is just a means for people to work together. Talking about nice ideas without development isnt going to go far.
Rahul
Rahul Sundaram wrote:
Unfortunately, it's not like you can write a couple of new applications and you're done. It would take some commitment by a distribution such as Fedora to bring the small bits together.
A distribution is just a means for people to work together. Talking about nice ideas without development isnt going to go far.
You are right. In my free time, I could contribute a list of existing interoperability and usability issues. I could file them as Bugzilla entries and create a meta-bug to group them together.
Would something like this be useful as a starting point?
I could also go a step further and attach a few small configuration patches for the individual package maintainers to apply.
Fixing code issues requires familiarity with several projects, which I don't have. Extending the Fedora administration tools requires Python, which I don't know.
On Thu, 2006-05-25 at 23:05 +0200, Bernardo Innocenti wrote:
Rahul Sundaram wrote:
Unfortunately, it's not like you can write a couple of new applications and you're done. It would take some commitment by a distribution such as Fedora to bring the small bits together.
A distribution is just a means for people to work together. Talking about nice ideas without development isnt going to go far.
You are right. In my free time, I could contribute a list of existing interoperability and usability issues. I could file them as Bugzilla entries and create a meta-bug to group them together.
Would something like this be useful as a starting point?
I could also go a step further and attach a few small configuration patches for the individual package maintainers to apply.
Fixing code issues requires familiarity with several projects, which I don't have. Extending the Fedora administration tools requires Python, which I don't know.
Yes. Filing bugs on issues would be a good starting point.
Rahul
LDAP sure isn't an easy beast to configure and run, expecially if you need TLS and replication.
Fedora Directory Server is relatively easy to set up, configure and mantain, and has a nice Java administration console.
On Wed, 2006-05-24 at 17:30 +0200, Felipe Alfaro Solana wrote:
has a nice Java administration console.
Sorry, I just can't agree with 'nice' and 'java' being used in conjunction.
ons, 24 05 2006 kl. 11:33 -0400, skrev Jesse Keating:
On Wed, 2006-05-24 at 17:30 +0200, Felipe Alfaro Solana wrote:
has a nice Java administration console.
Sorry, I just can't agree with 'nice' and 'java' being used in conjunction.
Quoted for truth.
I have yet to see a Java application which didn't redefine the term ugly in a new and hidious way.
- David
On 5/24/06, Bernardo Innocenti bernie@develer.com wrote:
Build System wrote:
glibc-2.4.90-9
- Sun May 21 2006 Jakub Jelinek jakub@redhat.com 2.4.90-9
- update from CVS
- big NIS+ changes
Maybe I'm just ignorant about the field, but is any RedHat/Fedora user still using NIS+ instead of LDAP in corporate environments?
I wonder whether NIS, NIS+, Hesiod and DB support in glibc could be dropped altogether to reduce the size of Core and simplify dependencies.
Maybe those NSS modules could just be splitted out and moved to Extras?
Sadly, NIS is still a product of choice for a lot of environments (as ugly and insecure as it is). I dont think I have ever seen a NIS+ environment at any of the organizations I have worked at.. but that was mainly due to the 'closed' nature of it. The main reason for NIS to be used is that it really only takes 2-3 files, a couple of little edits, and poof you have it working. I am just starting to look at Fedora Directory Server and it looks like it will take a LOT more work than that to get it working (or even getting a small LDAP service that would duplicate the 3 things most people use NIS for: user accounts, centralized passwords, and email aliases)
-
Bernardo Innocenti -
Build System -
David Nielsen -
Felipe Alfaro Solana -
Jesse Keating -
Paul Howarth -
Rahul Sundaram -
Rudolf Kastl -
seth vidal -
Stephen John Smoogen -
Tom Diehl