Re: TESTING - yum update for SL5
Testing has been successful thus far. We are planning on pushing this out next Tuesday, December 15, 2009. If you have had any issues with this version of yum, please let me know before then. Thanks Troy Dawson Troy J Dawson wrote: Hello, The kernel module plugin has been updated to deal with the situation where both a package that has a kernel module (such as openafs) is being updated at the same time that a kernel is being updated, while an old kernel is being removed. Two other bugs have been fixed - string TypeError bug - Reported and Fixed by Yannick Perret - negative sack length bug - Reported and Fixed by Tim Rupp To test or update SL5 --- yum --enablerepo=sl-testing update yum or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/yum/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/yum/ yum-3.2.22-22.sl.noarch.rpm Thanks Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
TESTING - rrdtool for SL4 and SL5
Hello, We are adding a new package to SLF 4 and 5, rrdtool. These packages will go out on Tuesday, December 15, 2009 We have already done alot of testing and debugging, but we would like it if others tested it would be good. Note: We have updated the spec file so that these packages are compatible with both epel and dag (which packaged rrdtool differently from each other) To test or update SL4 --- yum --enablerepo=sl-testing list rrdtool\* yum --enablerepo=sl-testing install rrdtool or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/40rolling/testing/i386/RPMS/rrdtool/ http://ftp.scientificlinux.org/linux/scientific/40rolling/testing/x86_64/RPMS/rrdtool/ rrdtool-1.2.30-2.sl4 SL5 --- yum --enablerepo=sl-testing list rrdtool\* yum --enablerepo=sl-testing install rrdtool or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/rrdtool/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/rrdtool/ rrdtool-1.3.9-2.sl5 Thanks Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __
FQDN in krb5.conf
Hi,
I have a question about using FQDN in krb5.conf.
It seems that Kerberos libraries do an extra DNS lookup if the krb5.conf
doesn't use complete FQDNs when specifying servers.
For example with a FNAL.GOV stanza in krb5.conf like this:
FNAL.GOV = {
default_domain = fnal.gov
admin_server = krb-fnal-admin.fnal.gov
kdc = krb-fnal-1.fnal.gov:88
kdc = krb-fnal-2.fnal.gov:88
kdc = krb-fnal-3.fnal.gov:88
kpasswd_protocol = SET_CHANGE
}
MIT Kerberos does an extra check to see if krb-fnal-admin.fnal.gov is a
FQDN. If the server names are specified as proper FQDNs (note the final
.). Then there is no need to do this check. If name resolution on
the client is slow, this can be a factor of 2 difference in time to get
a ticket (note that this was testing on our own realm and not FNAL.GOV).
FNAL.GOV = {
default_domain = fnal.gov
admin_server = krb-fnal-admin.fnal.gov.
kdc = krb-fnal-1.fnal.gov.:88
kdc = krb-fnal-2.fnal.gov.:88
kdc = krb-fnal-3.fnal.gov.:88
kpasswd_protocol = SET_CHANGE
}
Is there a reason not to use the proper FQDN? Most of the examples for
krb5.conf don't show using FQDNs.
I saw this in a note on the MIT Kerberos list:
http://mailman.mit.edu/pipermail/kerberos/2006-September/010545.html
Thanks,
Tom Rockwell
scientificlinux.org DNS downtime
Hello, Last night there was a problem with the name resolution of scientificlinux.org. All of our machines couldn't been looked up. There was a problem with our external DNS server. The problem has been fixed, and it shouldn't happen again. We apologize for any inconvenience this may have caused. Thank you for your patience. Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Why sl-srpms Instead of sl-source?
Yumdownloader relies on repository names ending in -source to tell whether or not it should enable them when one runs ``yumdownloader --source $package'' to grab the source for an rpm. But unlike most repositories, SL's source repository is called sl-srpms instead of sl-source, so the program doesn't work correctly for anything in the SL base repositories. Is there some historical reason for SL's strange naming scheme? Is it something that can change in a later release like 6.x?
