Re: sl-debuginfo, gpgcheck and mirrors

[Dr Andrew C Aitchison]

On Wed, 22 Apr 2009, Troy Dawson wrote:


Using mirrors vs mirrorlist
Last time I checked, people still preferred having a static over using the 
mirrorlist.  Majority of our users have a local mirror, and so change that 
anyway.  As for the rest, we haven't asked for a year or two.  Last time we 
asked, I believe the problem people had was not knowing if the mirror they 
were getting was being updated fast enough. And at that time, I think 
fastestmirror wasn't as good as it is nowdays.

But we could certainly ask again.


We have our own mirror so it doesn't really matter to me.
I've had problems (sorry can't remember the details off hand)
with mirrors not being up to date.
If you make the default mirrorlist it would be important that every
mirror in it is updated frequently - could you automatically check
and remove mirrors from the list if/when they aren't sufficiently
up to date ?

--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
a.c.aitchi...@dpmms.cam.ac.uk   http://www.dpmms.cam.ac.uk/~werdna

Re: sl-debuginfo, gpgcheck and mirrors

[Martin Jürgens]

Another argument for the mirrorlist is that if the SL-servers run out of
power or are broken people can still update / install SL.

Martin

Am Donnerstag, den 23.04.2009, 00:13 +0200 schrieb Martin Jürgens:
> Hi Troy,thanks for your fast reply.
> 
> Regarding static mirror vs mirrorlist:
> 
> When I configured my system the SL mirror seemed slow to me, so using
> mirrorlist could make things faster for some users which could be an
> advantage. Coming to the fear of not getting the latest updates: It
> should be possible to query the mirrors if they sync regulary (does
> centos do that?). If not, they could be taken out of the mirror list.
> But IMO the question is if it makes sense to create such an
> infrastructure having considered the current amount of users is not that
> huge (taken from the statistics at sl.org).
> 
> Ah and I have one last question to the gpgchecks. While it makes sense
> to me having them disabled if it is not possible to sign a certain
> package, why are they disabled for ATRPMs and DAG in the officiel
> yum-conf RPMs? I have enabled them manually and I do not run into any
> problems but have improved security :-)
> 
> Martin
> 
> Am Mittwoch, den 22.04.2009, 16:50 -0500 schrieb Troy Dawson:
> > Hi,
> > I'll answer the qestion inline
> > 
> > Martin Jürgens wrote:
> > > Hi,
> > > 
> > > sadly I was not able to use the bug tracker so I will use this list to
> > > address the issues / questions that I have in mind after using
> > > Scientific Linux for some time.
> > > 
> > > The first thing I noticed is that there is something wrong with the
> > > sl-debuginfo repository. yum repolist says the following:
> > > 
> > > sl-debuginfo Scientific Linux 5 debuginfo rpm's   enabled :
> > > 72
> > > 
> > > But having looked at
> > > ftp://ftp.scientificlinux.org/linux/scientific/5x/archive/debuginfo/
> > > there seem to be much more packages in that repo than 72. Is there 
> > > something
> > > wrong with the repodata?
> > > 
> > 
> > That is an oversight.  I'll fix the script and tomorrow when tomorrows 
> > errata go out, it should be fixed.
> > 
> > > The second thing is that both gpgcheck and the
> > > usage of mirrors is deactivated by default in yum.repos.d. I'd be 
> > > interested
> > > in knowing why that is, also because the gpgcheck can vastly improve
> > > security.
> > > 
> > 
> > gpgcheck
> > I would love to turn that on.  The problem is that we still cannot sign 
> > jdk.  Well, we've gotten it down to we cannot sign the x86_64 version. 
> > So we're getting close, and as soon as we can, we will.
> > 
> > Using mirrors vs mirrorlist
> > Last time I checked, people still preferred having a static over using 
> > the mirrorlist.  Majority of our users have a local mirror, and so 
> > change that anyway.  As for the rest, we haven't asked for a year or 
> > two.  Last time we asked, I believe the problem people had was not 
> > knowing if the mirror they were getting was being updated fast enough. 
> > And at that time, I think fastestmirror wasn't as good as it is nowdays.
> > But we could certainly ask again.
> > 
> > What do people think, should we switch to using the mirrorlist as the 
> > default?  Or should we stick with how we currently have things?
> > 
> > Troy

Re: sl-debuginfo, gpgcheck and mirrors

[Martin Jürgens]

Hi Troy,thanks for your fast reply.

Regarding static mirror vs mirrorlist:

When I configured my system the SL mirror seemed slow to me, so using
mirrorlist could make things faster for some users which could be an
advantage. Coming to the fear of not getting the latest updates: It
should be possible to query the mirrors if they sync regulary (does
centos do that?). If not, they could be taken out of the mirror list.
But IMO the question is if it makes sense to create such an
infrastructure having considered the current amount of users is not that
huge (taken from the statistics at sl.org).

Ah and I have one last question to the gpgchecks. While it makes sense
to me having them disabled if it is not possible to sign a certain
package, why are they disabled for ATRPMs and DAG in the officiel
yum-conf RPMs? I have enabled them manually and I do not run into any
problems but have improved security :-)

Martin

Am Mittwoch, den 22.04.2009, 16:50 -0500 schrieb Troy Dawson:
> Hi,
> I'll answer the qestion inline
> 
> Martin Jürgens wrote:
> > Hi,
> > 
> > sadly I was not able to use the bug tracker so I will use this list to
> > address the issues / questions that I have in mind after using
> > Scientific Linux for some time.
> > 
> > The first thing I noticed is that there is something wrong with the
> > sl-debuginfo repository. yum repolist says the following:
> > 
> > sl-debuginfo Scientific Linux 5 debuginfo rpm's   enabled :
> > 72
> > 
> > But having looked at
> > ftp://ftp.scientificlinux.org/linux/scientific/5x/archive/debuginfo/
> > there seem to be much more packages in that repo than 72. Is there something
> > wrong with the repodata?
> > 
> 
> That is an oversight.  I'll fix the script and tomorrow when tomorrows 
> errata go out, it should be fixed.
> 
> > The second thing is that both gpgcheck and the
> > usage of mirrors is deactivated by default in yum.repos.d. I'd be interested
> > in knowing why that is, also because the gpgcheck can vastly improve
> > security.
> > 
> 
> gpgcheck
> I would love to turn that on.  The problem is that we still cannot sign 
> jdk.  Well, we've gotten it down to we cannot sign the x86_64 version. 
> So we're getting close, and as soon as we can, we will.
> 
> Using mirrors vs mirrorlist
> Last time I checked, people still preferred having a static over using 
> the mirrorlist.  Majority of our users have a local mirror, and so 
> change that anyway.  As for the rest, we haven't asked for a year or 
> two.  Last time we asked, I believe the problem people had was not 
> knowing if the mirror they were getting was being updated fast enough. 
> And at that time, I think fastestmirror wasn't as good as it is nowdays.
> But we could certainly ask again.
> 
> What do people think, should we switch to using the mirrorlist as the 
> default?  Or should we stick with how we currently have things?
> 
> Troy

Re: sl-debuginfo, gpgcheck and mirrors

[Troy Dawson]

Brandon Galbraith wrote:
Would it be possible to check the logs from the servers serving the RPMs 
to see where the majority of the traffic is going to (onsite or off 
site), and make a decision based on that? Or perhaps have it as an 
install option (Update page: Option 1: Update from source repository? 
Option 2: Update from mirrors?).


-brandon



Hi,
No, this is for plain scientific linux users.  All of it is going 
offsite, or at least a huge portion.


On Wed, Apr 22, 2009 at 4:50 PM, Troy Dawson > wrote:


Hi,
I'll answer the qestion inline


Martin Jürgens wrote:

Hi,

sadly I was not able to use the bug tracker so I will use this
list to
address the issues / questions that I have in mind after using
Scientific Linux for some time.

The first thing I noticed is that there is something wrong with the
sl-debuginfo repository. yum repolist says the following:

sl-debuginfo Scientific Linux 5 debuginfo rpm's  
enabled :

72

But having looked at
ftp://ftp.scientificlinux.org/linux/scientific/5x/archive/debuginfo/
there seem to be much more packages in that repo than 72. Is
there something
wrong with the repodata?


That is an oversight.  I'll fix the script and tomorrow when
tomorrows errata go out, it should be fixed.


The second thing is that both gpgcheck and the
usage of mirrors is deactivated by default in yum.repos.d. I'd
be interested
in knowing why that is, also because the gpgcheck can vastly improve
security.


gpgcheck
I would love to turn that on.  The problem is that we still cannot
sign jdk.  Well, we've gotten it down to we cannot sign the x86_64
version. So we're getting close, and as soon as we can, we will.

Using mirrors vs mirrorlist
Last time I checked, people still preferred having a static over
using the mirrorlist.  Majority of our users have a local mirror,
and so change that anyway.  As for the rest, we haven't asked for a
year or two.  Last time we asked, I believe the problem people had
was not knowing if the mirror they were getting was being updated
fast enough. And at that time, I think fastestmirror wasn't as good
as it is nowdays.
But we could certainly ask again.

What do people think, should we switch to using the mirrorlist as
the default?  Or should we stick with how we currently have things?

Troy
-- 


--
__
Troy Dawson  daw...@fnal.gov  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI LMSS Group
__

Re: Updating to SL 5.3 issues

[Troy Dawson]

Avetisyan, Aram wrote:

Hello,

I followed the instructions for updating to SL 5.3 (from SL 5.1 + latest yum 
updates) on scientificlinux.org. It did not give any errors during the update, 
but I think something went very wrong because now I have a rather long list of 
problems such as:

1) During every boot, I get this message:

Bringing up interface wmaster0
Determining IP information for wmaster0... SIOCSIFFLAGS Operation not supported
SIOCSIFFLAGS: Operation not supported

The machine is frozen for about 2 minutes while it thinks about these 
SIOCSIFFLAGS after which it resumes booting.

2) The option to connect to wireless networks through Network Manager is grayed 
out. I have an Intel 4965AGN wireless card which worked perfectly fine before I 
tried updating, but now it doesn't seem to see the networks anymore -- the 
settings include a list of all of the connections with correct names and 
passwords, but the system acts as if there is no network in range.



1 and 2 are related.
First do a
  yum install iwl\*
This should get all the intel firmware we have, which was updated in the 
5.3 release.
If that still doesn't help please send me what you have in 
/etc/modprobe.conf


This whole NetworkManager update is just driving me nuts.  But I thought 
if you did an update from 5.2, 5.1, or 5.0 then it worked.



3) Going to certain websites with Firefox (e.g. Skype, where I went to 
redownload the program because there's no sound in the version I have installed 
anymore) causes a hard crash -- the system either reboots or freezes to the 
point where the only thing I can do is push the power button. There are no 
error messages.



Can you give us a specific example?  I know it's hard when it crashes 
when you get there, but if it's possible, it narrows things down when we 
have exact url's.



Is there a way to do a clean installation of SL 5.3 other than just formatting 
the partition and starting from scratch? If I reformat, do I need both DVD 
images or just one (the readme speaks of one image, but there are two available 
for download)?

Thanks.

-- Aram


Troy
--
__
Troy Dawson  daw...@fnal.gov  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI LMSS Group
__

Re: sl-debuginfo, gpgcheck and mirrors

[Brandon Galbraith]

Would it be possible to check the logs from the servers serving the RPMs to
see where the majority of the traffic is going to (onsite or off site), and
make a decision based on that? Or perhaps have it as an install option
(Update page: Option 1: Update from source repository? Option 2: Update from
mirrors?).

-brandon

On Wed, Apr 22, 2009 at 4:50 PM, Troy Dawson  wrote:

> Hi,
> I'll answer the qestion inline
>
> Martin Jürgens wrote:
>
>> Hi,
>>
>> sadly I was not able to use the bug tracker so I will use this list to
>> address the issues / questions that I have in mind after using
>> Scientific Linux for some time.
>>
>> The first thing I noticed is that there is something wrong with the
>> sl-debuginfo repository. yum repolist says the following:
>>
>> sl-debuginfo Scientific Linux 5 debuginfo rpm's   enabled :
>> 72
>>
>> But having looked at
>> ftp://ftp.scientificlinux.org/linux/scientific/5x/archive/debuginfo/
>> there seem to be much more packages in that repo than 72. Is there
>> something
>> wrong with the repodata?
>>
>>
> That is an oversight.  I'll fix the script and tomorrow when tomorrows
> errata go out, it should be fixed.
>
>  The second thing is that both gpgcheck and the
>> usage of mirrors is deactivated by default in yum.repos.d. I'd be
>> interested
>> in knowing why that is, also because the gpgcheck can vastly improve
>> security.
>>
>>
> gpgcheck
> I would love to turn that on.  The problem is that we still cannot sign
> jdk.  Well, we've gotten it down to we cannot sign the x86_64 version. So
> we're getting close, and as soon as we can, we will.
>
> Using mirrors vs mirrorlist
> Last time I checked, people still preferred having a static over using the
> mirrorlist.  Majority of our users have a local mirror, and so change that
> anyway.  As for the rest, we haven't asked for a year or two.  Last time we
> asked, I believe the problem people had was not knowing if the mirror they
> were getting was being updated fast enough. And at that time, I think
> fastestmirror wasn't as good as it is nowdays.
> But we could certainly ask again.
>
> What do people think, should we switch to using the mirrorlist as the
> default?  Or should we stick with how we currently have things?
>
> Troy
> --
> __
> Troy Dawson  daw...@fnal.gov  (630)840-6468
> Fermilab  ComputingDivision/LCSI/CSI LMSS Group
> __
>



-- 
Brandon Galbraith
Mobile: 630.400.6992
FNAL: 630.840.2141

Re: sl-debuginfo, gpgcheck and mirrors

[Troy Dawson]

Hi,
I'll answer the qestion inline

Martin Jürgens wrote:

Hi,

sadly I was not able to use the bug tracker so I will use this list to
address the issues / questions that I have in mind after using
Scientific Linux for some time.

The first thing I noticed is that there is something wrong with the
sl-debuginfo repository. yum repolist says the following:

sl-debuginfo Scientific Linux 5 debuginfo rpm's   enabled :
72

But having looked at
ftp://ftp.scientificlinux.org/linux/scientific/5x/archive/debuginfo/
there seem to be much more packages in that repo than 72. Is there something
wrong with the repodata?



That is an oversight.  I'll fix the script and tomorrow when tomorrows 
errata go out, it should be fixed.



The second thing is that both gpgcheck and the
usage of mirrors is deactivated by default in yum.repos.d. I'd be interested
in knowing why that is, also because the gpgcheck can vastly improve
security.



gpgcheck
I would love to turn that on.  The problem is that we still cannot sign 
jdk.  Well, we've gotten it down to we cannot sign the x86_64 version. 
So we're getting close, and as soon as we can, we will.


Using mirrors vs mirrorlist
Last time I checked, people still preferred having a static over using 
the mirrorlist.  Majority of our users have a local mirror, and so 
change that anyway.  As for the rest, we haven't asked for a year or 
two.  Last time we asked, I believe the problem people had was not 
knowing if the mirror they were getting was being updated fast enough. 
And at that time, I think fastestmirror wasn't as good as it is nowdays.

But we could certainly ask again.

What do people think, should we switch to using the mirrorlist as the 
default?  Or should we stick with how we currently have things?


Troy
--
__
Troy Dawson  daw...@fnal.gov  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI LMSS Group
__

sl-debuginfo, gpgcheck and mirrors

[Martin Jürgens]

Hi,

sadly I was not able to use the bug tracker so I will use this list to
address the issues / questions that I have in mind after using
Scientific Linux for some time.

The first thing I noticed is that there is something wrong with the
sl-debuginfo repository. yum repolist says the following:

sl-debuginfo Scientific Linux 5 debuginfo rpm's   enabled :
72

But having looked at
ftp://ftp.scientificlinux.org/linux/scientific/5x/archive/debuginfo/
there seem to be much more packages in that repo than 72. Is there something
wrong with the repodata?

The second thing is that both gpgcheck and the
usage of mirrors is deactivated by default in yum.repos.d. I'd be interested
in knowing why that is, also because the gpgcheck can vastly improve
security.


Thanks,

Martin

Re: Updating to SL 5.3 issues

[Connie Sieh]

On Wed, 22 Apr 2009, Phil Perry wrote:


Avetisyan, Aram wrote:

Hello,

I followed the instructions for updating to SL 5.3 (from SL 5.1 + latest yum 
updates) on scientificlinux.org. It did not give any errors during the update, 
but I think something went very wrong because now I have a rather long list of 
problems such as:

1) During every boot, I get this message:

Bringing up interface wmaster0
Determining IP information for wmaster0... SIOCSIFFLAGS Operation not supported
SIOCSIFFLAGS: Operation not supported

The machine is frozen for about 2 minutes while it thinks about these 
SIOCSIFFLAGS after which it resumes booting.

2) The option to connect to wireless networks through Network Manager is grayed 
out. I have an Intel 4965AGN wireless card which worked perfectly fine before I 
tried updating, but now it doesn't seem to see the networks anymore -- the 
settings include a list of all of the connections with correct names and 
passwords, but the system acts as if there is no network in range.



I think these two issues are related to the updated driver for iwl4965
in 5.3. SL5.2 used the iwl4965 driver whereas 5.3 uses the new iwlagn
driver. They use *different* firmware, so a user updating from 5.2 ->
5.3 with previously working wireless will experience the issues you
describe if the correct firmware is not installed.

In /etc/firmware you will need iwlwifi-4965-2.ucode (note the -2
revision is required by the new iwlagn driver).

RPMforge has the correct firmware packages (yum install
iwl4965-firmware). I'm not sure what SL firmware packages are available
nor what firmwares these packages contain.


The firmware is in iwlwifi-4965-ucode which is part of SLF 5.3 .

  /lib/firmware/LICENSE.iwlwifi-4965-ucode
  /lib/firmware/iwlwifi-4965-1.ucode
  /lib/firmware/iwlwifi-4965-2.ucode
  /lib/firmware/iwlwifi-4965.ucode

-connie sieh



Hope that helps,

Phil

Re: Updating to SL 5.3 issues

[Phil Perry]

Avetisyan, Aram wrote:

Hello,

I followed the instructions for updating to SL 5.3 (from SL 5.1 + latest yum 
updates) on scientificlinux.org. It did not give any errors during the update, 
but I think something went very wrong because now I have a rather long list of 
problems such as:

1) During every boot, I get this message:

Bringing up interface wmaster0
Determining IP information for wmaster0... SIOCSIFFLAGS Operation not supported
SIOCSIFFLAGS: Operation not supported

The machine is frozen for about 2 minutes while it thinks about these 
SIOCSIFFLAGS after which it resumes booting.

2) The option to connect to wireless networks through Network Manager is grayed 
out. I have an Intel 4965AGN wireless card which worked perfectly fine before I 
tried updating, but now it doesn't seem to see the networks anymore -- the 
settings include a list of all of the connections with correct names and 
passwords, but the system acts as if there is no network in range.



I think these two issues are related to the updated driver for iwl4965 
in 5.3. SL5.2 used the iwl4965 driver whereas 5.3 uses the new iwlagn 
driver. They use *different* firmware, so a user updating from 5.2 -> 
5.3 with previously working wireless will experience the issues you 
describe if the correct firmware is not installed.


In /etc/firmware you will need iwlwifi-4965-2.ucode (note the -2 
revision is required by the new iwlagn driver).


RPMforge has the correct firmware packages (yum install 
iwl4965-firmware). I'm not sure what SL firmware packages are available 
nor what firmwares these packages contain.


Hope that helps,

Phil

Updating to SL 5.3 issues

[Avetisyan, Aram]

Hello,

I followed the instructions for updating to SL 5.3 (from SL 5.1 + latest yum 
updates) on scientificlinux.org. It did not give any errors during the update, 
but I think something went very wrong because now I have a rather long list of 
problems such as:

1) During every boot, I get this message:

Bringing up interface wmaster0
Determining IP information for wmaster0... SIOCSIFFLAGS Operation not supported
SIOCSIFFLAGS: Operation not supported

The machine is frozen for about 2 minutes while it thinks about these 
SIOCSIFFLAGS after which it resumes booting.

2) The option to connect to wireless networks through Network Manager is grayed 
out. I have an Intel 4965AGN wireless card which worked perfectly fine before I 
tried updating, but now it doesn't seem to see the networks anymore -- the 
settings include a list of all of the connections with correct names and 
passwords, but the system acts as if there is no network in range.

3) Going to certain websites with Firefox (e.g. Skype, where I went to 
redownload the program because there's no sound in the version I have installed 
anymore) causes a hard crash -- the system either reboots or freezes to the 
point where the only thing I can do is push the power button. There are no 
error messages.

Is there a way to do a clean installation of SL 5.3 other than just formatting 
the partition and starting from scratch? If I reformat, do I need both DVD 
images or just one (the readme speaks of one image, but there are two available 
for download)?

Thanks.

-- Aram

Re: kernel lockd does not honor requested lockd ports

[John Hill]

I've just been fighting the same issue on a SL 4.7 system (kernel
2.6.9-78.0.17) and found the same solution. If you look inside
/etc/init.d/nfs you will see that sysctl is called to update
the appropriate parameters. However this does not work, and I did
discover that the parameters do not exist when the "sysctl -w" is
done.

John

Eve V. E. Kovacs wrote:

Yes, I tore my hair out on this one last year. The solution is:
In modprobe.conf on the nfs server add the following line:

options lockd nlm_udpport=6667 nlm_tcpport=6667

(here 6667 is the port number to which lockd is fixed)

The reboot your server.

Eve

On Tue, 21 Apr 2009, Ken Teh wrote:


Date: Tue, 21 Apr 2009 17:02:04 -0500
From: Ken Teh 
To: scientific-linux-users 
Subject: kernel lockd does not honor requested lockd ports

I've fixed the various nfs ports in my firewall config and have 
propagated these ports to /etc/sysconfig/nfs.  All the ports are 
honored except for the lockd ports.  I've even tried setting the ports 
in sysctl.conf and appending them to the kernel boot in grub.conf.  
rpcinfo -p shows that the kernel (2.6.18-128.1.6.el5) basically 
ignores me.  NFS clients are mounting via NFSv3.  Ignoring the lockd 
numbers creates apparently creates problems for some applications, 
presumably because the application is requesting file locks.  For 
example, firefox won't run when launched in a user's home directory 
that is mounted remotely from the server.


Has anyone seen this problem?  What's the fix?

Ken



***
Eve Kovacs
Argonne National Laboratory,
Room F149, Bldg. 362, HEP
9700 S. Cass Ave.
Argonne, IL 60439 USA
Phone: (630)-252-6208
Fax:   (630)-252-5047
email: kov...@hep.anl.gov
***