Re: a year later - CERN move to Centos - what are we doing?

[lejeczek]

I think we see two groups of people here, taking part in 
this "exciting" debate.


One is, people who genuinely try to learn a bit about more 
concrete plans Fermilab have(or don't have) for the future 
of Scientificlinux - and they do it here on the list because 
they can sroogle all over the Net and they won't find any 
solid, ideally rendered by the very source itself statement.


The second group is people who don't give a toss, a good 
chance is it's because they have not seen much beside 
Scientificlinux and they really believe it's very unique 
indeed. You can see scientist type of mentality here -- I 
have got my one little or big app, it runs great! and I'm 
happy with it and I can say I do it all on by myself cause I 
do not have to deal with any commercial third entities 
(which is very important for a scientist) -- very simplistic 
and egotistic attitude, but works. And a good chance is this 
bunch don't have to even ask about bigger picture. Some 
individuals from this group can even be rude and hostile 
towards others, even if only asked about sharing a thought 
or two on the issue.


Well, like esteemed fellows already said - we're free to do 
as we wish, fortunately, only unfortunate is that we cannot 
always make fully informed decisions. I guess that's 
science, that's life. Heh. :)

b.w.



On 13/01/16 10:13, Iosif Fettich wrote:

Hi there,

anyone who wants to go with centos, is free to do so, 
right? So just go and do it and don't 'fuss' about it on 
SL mail list.


Thanks for the nice advice.

Would you have another one too? On which list should 
current SL users ask/discuss about the short/long term 
plans regarding SL? And/or of the problems related with a 
migration from/to SL?


We all should be grateful for continuing support of 
Fermilab for SL builds.


That's something we most probably all on this list agree 
with unconditionally.


Thank you,

Iosif Fettich

--- 

Iosif Fettich | e-mail: ifett...@netsoft.ro   phone+fax: 
+40-265-260256
Gen. Manager  | web:http://www.netsoft.ro phone: 
+40-365-806800
NetSoft SRL   | GPGkey: 
http://www.netsoft.ro/ifettich/public_gpg_key

Re: a year later - CERN move to Centos - what are we doing?

[Karel Lang AFD]

Hi,
anyone who wants to go with centos, is free to do so, right? So just go 
and do it and don't 'fuss' about it on SL mail list.


We all should be grateful for continuing support of Fermilab for SL builds.


--
*Karel Lang*
*Unix/Linux Administration*
l...@afd.cz | +420 731 13 40 40
AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz


On 01/12/2016 10:29 PM, lejeczek wrote:

On 12/01/16 20:30, Mark Stodola wrote:

Since this is becoming a top-post thread, I will continue the trend.

CentOS does not offer a support contract like RHEL.  Why would a
company compete with itself?  It is essentially a community supported
release of RHEL, just like SL.

Of course, some one please correct me if I am wrong here...

This is not a new topic, and was discussed at length when RedHat
announced the acquisition of CentOS and changes to the build process.
To my knowledge, the SL team had discussions with the CentOS and
RedHat people on how to move forward.  The SL team decided to continue
as a complete separate distribution instead of become in extra
repository/site for the foreseeable future.

One of the key features I like about SL is the ability to stay on a
specific point release and still receive relevant updates. There are
probably several other reasons Connie or Pat could elaborate on as well.

In the end, it is up to personal/company preference with any
distribution you chose to use.  That is part of what open source is
about.  Arguing for distribution usage/mergers doesn't really do
anything productive here in a users' mailing list.

Of course it does.

When somebody mentions fondness towards the support SL offers - what
does it mean? - I always thought SL support has always been exclusively
community(users) based + contributing developers. Am I wrong and missing
that somewhere there we can get some extra level of support?

Now, CERN and affiliates, associates, whatever or whoever decides to
follow this path is going to drift a bit away, if not completely. There
was one scientificLinux both great labs shared - now they are parting
away in a sense. The same would happen with users. Opensource community,
though the greatest in the world had always had problems coming together.

And "complete separate distribution" I think is a bit abused notion in
case of SL. I've been a SL user for many years and I'm grateful for it.
Even if only for the fact that one can get such a great product in its
entirety without getting tied up in some commercial contracts, greedy
and doggy as they usually are.

I don't want to argue superiority of one over the other in terms of
point-release, updates and/or their promptness, I did not mean to, not
much to argue there, anybody can check it themselves.

If it was discussed here on the list before I apologize - I must have
rushed my search for the topic on the list, I only found a 2014 old
topic and then CERN's news about 2015 move.

I've learned what I sought, many thanks.



-Mark


On 01/12/2016 02:10 PM, Miles O'Neal wrote:

Has CentOS got support yet? My employer moved to RHEL because we got
tired of fighting third party vendors over their support on non-RHEL
platforms, but I personally always found SL to be more consistent and
quicker to release... and they had much better support.

On 01/12/2016 02:04 PM, lejeczek wrote:

hi,
after my first post I made a move, I should say a smaller rather, I
did migrate a small HA cluster from SL7.1 to Centos7.2.
Instructions to do that I'm sure everybody can easily look up, just
one tiny manual intervention was needed above what is already covered
by a doc on Centos website.
But most importantly nothing broke, all the usual servers, web, mail,
other net related services including HA carried on seamlessly.
Like I said earlier, and everybody knows, a lot, a lot is already
shared, differences boil down to maybe a philosophy behind each
organization responsible for each snip-off, some organizational and
administrative processes, protocols.
Slight advantage seems that Centos offers, but expected as they are
closer to the source in the lifecycle supply chain, is higher revision
of some rpm packages, I see I get slightly newer kernel for example,
etc.

If I was to voice my opinion out - and scientific devel & other
responsible culprits are listening - then I say: go for it, get
together, merge userbase, share devel jobs, duties, etc. Merge/share
or even better, tell Redhat we want to use their, shared by all, bug
reporting system.

I've decided, I'll be moving over to Centos, gradually but surely.
Note, one thing to remember if you did SL -> Centos, afterwards, is
yum repos, make sure what you have enabled there.

cheers

On 12/01/16 09:48, lejeczek wrote:

hi everybody,

I've wondered and got curious, what do you guys, gals think about
that move?
More importantly do you think it's a step we SL users should also
consider?
CERN mention there were talks between them, Fermilab - what are
Fermilab plans with regards to future releases, with regards to SL in

Re: a year later - CERN move to Centos - what are we doing?

[Iosif Fettich]

Hi there,

anyone who wants to go with centos, is free to do so, right? So just go and 
do it and don't 'fuss' about it on SL mail list.


Thanks for the nice advice.

Would you have another one too? On which list should current SL users 
ask/discuss about the short/long term plans regarding SL? And/or of the 
problems related with a migration from/to SL?



We all should be grateful for continuing support of Fermilab for SL builds.


That's something we most probably all on this list agree with 
unconditionally.


Thank you,

Iosif Fettich

---
Iosif Fettich | e-mail: ifett...@netsoft.ro   phone+fax: +40-265-260256
Gen. Manager  | web:http://www.netsoft.ro phone: +40-365-806800
NetSoft SRL   | GPGkey: http://www.netsoft.ro/ifettich/public_gpg_key

Re: a year later - CERN move to Centos - what are we doing?

[Alec T. Habig]

Konstantin Olchanski writes:
> The installer for both have the same idiotic "you *must* create a fake
> user or no login prompt for you!",

If you're not making a local user, then you've probably got a network
authentication scheme.

In which case, you're probably deploying more than one machine.  Take a
look at making a kickstart file to automate the install process.  In
kickstart, you don't have to make a dummy user, you can just define your
network authentication setup.  And much, much more: then use that same
script to install on as many machines as you want.

Finally sat down to figure this out, and even for my measly handful of
machines, it was worth it.

> and the same "you *must* use the disk partition tool designed by
> dummies for dummies".

likewise solved by kickstart.

although even interactively you can still use fdisk from the shell,
certainly not a dumbed-down tool.  Perhaps too much in the other
direction :)

-- 
   Alec Habig
 University of Minnesota Duluth
 Dept. of Physics and Astronomy
ha...@neutrino.d.umn.edu
   http://neutrino.d.umn.edu/~habig/

Re: a year later - CERN move to Centos - what are we doing?

[Konstantin Olchanski]

On Wed, Jan 13, 2016 at 07:59:43AM -0600, Alec T. Habig wrote:
> Konstantin Olchanski writes:
> > The installer for both have the same idiotic "you *must* create a fake
> > user or no login prompt for you!",
> 
> If you're not making a local user, then you've probably got a network
> authentication scheme.
> 

Indeed. We use NIS. Support for NIS was removed in the el7 installer. Rejoyce!

>
> In which case, you're probably deploying more than one machine.  Take a
> look at making a kickstart file to automate the install process.  In
> kickstart, you don't have to make a dummy user, you can just define your
> network authentication setup.  And much, much more: then use that same
> script to install on as many machines as you want.
> 

Indeed. Have been using kickstart installs for years. CD/DVD kickstarts,
PXE-network-booted kickstarts, now mostly USB-flash-booted kickstarts.

In our environement we cannot do a one-size-fits-all kickstart,
so possibility to configure NIS during installation was quite handy.
Now it becomes a post-install step - login as root, run authconfig.

Actually now, due to this "must create, then delete fake user, which will also 
use a UID
colliding with our historic UID allocation scheme", non-kickstart vanilla
installer is pretty much useless.

>
> > and the same "you *must* use the disk partition tool designed by
> > dummies for dummies".
> 
> likewise solved by kickstart.
> 

The kickstart disk partitioning tool is even dumber than they new GUI tool,
only useful for "one-size-fits-all" cases where you also do not mind 
accidentally
deleting the contents of all disks. (yes, open the machine, disconnect disks,
install, reconnect disks, close the machine, thanks, but no thanks).

At least the el7 installer does not overwrite the bootloader of the *installer* 
disk
and seems to correctly install the boot loader for raid1 mirrored slash 
partitions.

P.S.

I keep banging about all this stuff because over the last 20 years all I see
is each new installer only reluctantly fix a few of the old bugs, but 
consistently
add new "features" which are not improvements.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: a year later - CERN move to Centos - what are we doing?

[jdow]

There is at least one other sub group around here who value generally quiet 
sober support when they have a problem. Ubuntu and many other distros are 
quality distros, and perhaps better support what some people want. But the 
Ubuntu and Fedora mailing lists and support are unbelievably noisy and getting 
help often (usually?)requires rhinoceros hide and extreme persistence. This very 
mailing list which is getting defiled by this pointless discussion is what I 
value about SL. This list is mercifully seldom sullied by trolls. And the SL 
distro itself is competent and has what I need, a few smart people supporting me 
on the mailing list and reasonably timely updates. So, every time I even think 
of moving I slap myself across the face and go do something important.


{^_^}   Joanne

On 2016-01-13 02:43, lejeczek wrote:

I think we see two groups of people here, taking part in this "exciting" debate.

One is, people who genuinely try to learn a bit about more concrete plans
Fermilab have(or don't have) for the future of Scientificlinux - and they do it
here on the list because they can sroogle all over the Net and they won't find
any solid, ideally rendered by the very source itself statement.

The second group is people who don't give a toss, a good chance is it's because
they have not seen much beside Scientificlinux and they really believe it's very
unique indeed. You can see scientist type of mentality here -- I have got my one
little or big app, it runs great! and I'm happy with it and I can say I do it
all on by myself cause I do not have to deal with any commercial third entities
(which is very important for a scientist) -- very simplistic and egotistic
attitude, but works. And a good chance is this bunch don't have to even ask
about bigger picture. Some individuals from this group can even be rude and
hostile towards others, even if only asked about sharing a thought or two on the
issue.

Well, like esteemed fellows already said - we're free to do as we wish,
fortunately, only unfortunate is that we cannot always make fully informed
decisions. I guess that's science, that's life. Heh. :)
b.w.



On 13/01/16 10:13, Iosif Fettich wrote:

Hi there,


anyone who wants to go with centos, is free to do so, right? So just go and
do it and don't 'fuss' about it on SL mail list.


Thanks for the nice advice.

Would you have another one too? On which list should current SL users
ask/discuss about the short/long term plans regarding SL? And/or of the
problems related with a migration from/to SL?


We all should be grateful for continuing support of Fermilab for SL builds.


That's something we most probably all on this list agree with unconditionally.

Thank you,

Iosif Fettich

---
Iosif Fettich | e-mail: ifett...@netsoft.ro   phone+fax: +40-265-260256
Gen. Manager  | web:http://www.netsoft.ro phone: +40-365-806800
NetSoft SRL   | GPGkey: http://www.netsoft.ro/ifettich/public_gpg_key

Re: a year later - CERN move to Centos - what are we doing?

[Graham Allan]

On 01/13/2016 01:30 PM, Konstantin Olchanski wrote:



and the same "you *must* use the disk partition tool designed by
dummies for dummies".


likewise solved by kickstart.



The kickstart disk partitioning tool is even dumber than they new GUI tool,
only useful for "one-size-fits-all" cases where you also do not mind 
accidentally
deleting the contents of all disks. (yes, open the machine, disconnect disks,
install, reconnect disks, close the machine, thanks, but no thanks).


Using %pre in the kickstart file is the way to fix this, but you do need
to do all the work yourself. I suppose I could share our %pre section 
which examines disks and decides which to install on (it waits for 
confirmation if it can't determine the drive itself). The logic is 
simply to look for the first drive which either has no partition table 
or has a /boot directory (ie reinstall). No claims that this is perfect 
in any way, we hacked it together over the years and it works for us 
(with SL6).


For the post-config stuff we use %post to set our configuration 
management system (cfengine) to run after reboot.



##
# Figure out where to install to

# make sure USB storage devices are GONE
modprobe -r usb_storage

mkdir /mnt/tmp

for i in `ls /dev/sd?`; do
CANDIDATE_DISK="$i"

echo "Checking $CANDIDATE_DISK for partition table" | tee -a /tmp/ks.log >> 
/dev/tty3

if parted -s "$CANDIDATE_DISK" print >/dev/null; then
echo "parted found a partition table" | tee -a /tmp/ks.log >> /dev/tty3
if mount "${CANDIDATE_DISK}1" /mnt/tmp; then
if [ -d /mnt/tmp/boot ]; then
INSTALL_DISK=$CANDIDATE_DISK
echo "Found /boot on ${CANDIDATE_DISK}1, using $CANDIDATE_DISK as system 
disk" | tee -a /tmp/ks.log >> /dev/tty3
umount /mnt/tmp
break
else
echo "Couldn't find /boot on ${CANDIDATE_DISK}1, moving on to next 
disk..." | tee -a /tmp/ks.log >> /dev/tty3
umount /mnt/tmp
fi
else
echo "Failed to mount ${CANDIDATE_DISK}1, moving on to next disk..." | 
tee -a /tmp/ks.log >> /dev/tty3
fi
else
echo "parted found no partition table, using $CANDIDATE_DISK as system disk" 
| tee -a /tmp/ks.log >> /dev/tty3
INSTALL_DISK="$CANDIDATE_DISK"
break
fi
done

if [ "${INSTALL_DISK}x" = "x" ]; then
echo "" >> /dev/tty1
echo "Initial check failed to find a suitable system disk!" >> /dev/tty1
echo "" >> /dev/tty1
for i in `ls /dev/sd?`; do
CANDIDATE_DISK="$i"
if mount "${CANDIDATE_DISK}1" /mnt/tmp; then
if ! [ -d /mnt/tmp/boot ]; then
echo -e "\n\nCouldn't find /boot on ${CANDIDATE_DISK}1" >> 
/dev/tty1
echo -n "Partition table for ${CANDIDATE_DISK}:" >> /dev/tty1
fdisk -l ${CANDIDATE_DISK} >> /dev/tty1
doit="default"
while ! echo "$doit" | grep -P "([Y|y]es|[N|n]o)" > /dev/null 
2>&1; do
echo -n "Install linux on ${CANDIDATE_DISK}? [Yes/No] " >> 
/dev/tty1
read doit
done
if echo "$doit" | grep -P "[Y|y]es" > /dev/null 2>&1; then
INSTALL_DISK="$CANDIDATE_DISK"
umount /mnt/tmp
break
else
echo "moving on to next disk..." >> /dev/tty1
fi
umount /mnt/tmp
fi
else
echo -ne "\n\nPartition table for ${CANDIDATE_DISK}:" >> /dev/tty1
fdisk -l ${CANDIDATE_DISK} >> /dev/tty1
doit="default"
while ! echo "$doit" | grep -P "([Y|y]es|[N|n]o)" > /dev/null 2>&1; 
do
echo -n "Install linux on ${CANDIDATE_DISK}? [Yes/No] " >> 
/dev/tty1
read doit
done
if echo "$doit" | grep -P "[Y|y]es" > /dev/null 2>&1; then
INSTALL_DISK="$CANDIDATE_DISK"
break
else
echo "moving on to next disk..." >> /dev/tty1
fi
fi
done

if [ "${INSTALL_DISK}x" = "x" ]; then
echo -e "\n" >> 
/dev/tty1
echo "Failed to find a suitable system disk" >> /dev/tty1
echo "The system will be rebooted when you press Ctrl-C or Ctrl-Alt-Delete." 
>> /dev/tty1
echo "" >> /dev/tty1
while true; do
sleep 1
done

> fi
> fi


echo "Installing linux to $INSTALL_DISK" | tee -a /tmp/ks.log >> /dev/tty3
echo "Installing linux to $INSTALL_DISK" >> /dev/tty1
echo "" >> /dev/tty1
# Done figuring out where to install
###


#Write a file out to be 

Re: a year later - CERN move to Centos - what are we doing?

[Miles O'Neal]

On 01/13/2016 02:42 PM, Graham Allan wrote:

On 01/13/2016 01:30 PM, Konstantin Olchanski wrote:



and the same "you *must* use the disk partition tool designed by
dummies for dummies".


likewise solved by kickstart.



The kickstart disk partitioning tool is even dumber than they new GUI 
tool,
only useful for "one-size-fits-all" cases where you also do not mind 
accidentally
deleting the contents of all disks. (yes, open the machine, 
disconnect disks,

install, reconnect disks, close the machine, thanks, but no thanks).


Using %pre in the kickstart file is the way to fix this, but you do need
to do all the work yourself. I suppose I could share our %pre section 
which examines disks and decides which to install on (it waits for 
confirmation if it can't determine the drive itself). The logic is 
simply to look for the first drive which either has no partition table 
or has a /boot directory (ie reinstall). No claims that this is 
perfect in any way, we hacked it together over the years and it works 
for us (with SL6).


For the post-config stuff we use %post to set our configuration 
management system (cfengine) to run after reboot.



##
# Figure out where to install to

# make sure USB storage devices are GONE
modprobe -r usb_storage

mkdir /mnt/tmp

for i in `ls /dev/sd?`; do
CANDIDATE_DISK="$i"

echo "Checking $CANDIDATE_DISK for partition table" | tee -a 
/tmp/ks.log >> /dev/tty3


if parted -s "$CANDIDATE_DISK" print >/dev/null; then
echo "parted found a partition table" | tee -a /tmp/ks.log >> 
/dev/tty3

if mount "${CANDIDATE_DISK}1" /mnt/tmp; then
if [ -d /mnt/tmp/boot ]; then
INSTALL_DISK=$CANDIDATE_DISK
echo "Found /boot on ${CANDIDATE_DISK}1, using 
$CANDIDATE_DISK as system disk" | tee -a /tmp/ks.log >> /dev/tty3

umount /mnt/tmp
break
else
echo "Couldn't find /boot on ${CANDIDATE_DISK}1, 
moving on to next disk..." | tee -a /tmp/ks.log >> /dev/tty3

umount /mnt/tmp
fi
else
echo "Failed to mount ${CANDIDATE_DISK}1, moving on to 
next disk..." | tee -a /tmp/ks.log >> /dev/tty3

fi
else
echo "parted found no partition table, using $CANDIDATE_DISK 
as system disk" | tee -a /tmp/ks.log >> /dev/tty3

INSTALL_DISK="$CANDIDATE_DISK"
break
fi
done

if [ "${INSTALL_DISK}x" = "x" ]; then
echo "" >> 
/dev/tty1
echo "Initial check failed to find a suitable system disk!" >> 
/dev/tty1
echo "" >> 
/dev/tty1

for i in `ls /dev/sd?`; do
CANDIDATE_DISK="$i"
if mount "${CANDIDATE_DISK}1" /mnt/tmp; then
if ! [ -d /mnt/tmp/boot ]; then
echo -e "\n\nCouldn't find /boot on 
${CANDIDATE_DISK}1" >> /dev/tty1
echo -n "Partition table for ${CANDIDATE_DISK}:" >> 
/dev/tty1

fdisk -l ${CANDIDATE_DISK} >> /dev/tty1
doit="default"
while ! echo "$doit" | grep -P "([Y|y]es|[N|n]o)" > 
/dev/null 2>&1; do
echo -n "Install linux on ${CANDIDATE_DISK}? 
[Yes/No] " >> /dev/tty1

read doit
done
if echo "$doit" | grep -P "[Y|y]es" > /dev/null 2>&1; 
then

INSTALL_DISK="$CANDIDATE_DISK"
umount /mnt/tmp
break
else
echo "moving on to next disk..." >> /dev/tty1
fi
umount /mnt/tmp
fi
else
echo -ne "\n\nPartition table for ${CANDIDATE_DISK}:" >> 
/dev/tty1

fdisk -l ${CANDIDATE_DISK} >> /dev/tty1
doit="default"
while ! echo "$doit" | grep -P "([Y|y]es|[N|n]o)" > 
/dev/null 2>&1; do
echo -n "Install linux on ${CANDIDATE_DISK}? [Yes/No] 
" >> /dev/tty1

read doit
done
if echo "$doit" | grep -P "[Y|y]es" > /dev/null 2>&1; then
INSTALL_DISK="$CANDIDATE_DISK"
break
else
echo "moving on to next disk..." >> /dev/tty1
fi
fi
done

if [ "${INSTALL_DISK}x" = "x" ]; then
echo -e 
"\n" >> /dev/tty1

echo "Failed to find a suitable system disk" >> /dev/tty1
echo "The system will be rebooted when you press Ctrl-C or 
Ctrl-Alt-Delete." >> /dev/tty1
echo "" 
>> /dev/tty1

while true; do
sleep 1
done

> fi
> fi


echo "Installing linux to $INSTALL_DISK" | tee -a /tmp/ks.log >> 
/dev/tty3

echo "Installing linux to $INSTALL_DISK" >> /dev/tty1
echo "" >> /dev/tty1
# Done 

Re: a year later - CERN move to Centos - what are we doing?

[Konstantin Olchanski]

On Wed, Jan 13, 2016 at 10:51:26AM -0600, Jim Campbell wrote:
> 
> As I understand it, one of the key values of SL is that it allows you to
> stay on a point release and obtain only security fixes for your packages
> (someone else mentioned this, too). This is important when running
> scientific experiments where you can't allow changes in software to
> impact your research results. Unless something has changed, neither
> CentOS nor the North American Upstream Vendor provide this service. This
> feature from Scientific Linux is a valuable one if you need it.
> 


Something strange happened during the move from el6 to el7 - 

CERN Linux el6 was always automatically self-updating to latest point release,
without causing any problems, so I came to like that and now configure SL6 
machines
to automatically update (using the SL6x repo).

Now CERN Linux el7 comes in and I see the machines installed as 7.1 stay there,
no automatic update to 7.2. Odd.

Then here, I see same with CentOS7 - no automatic updates by default, no 
automatic
updates to latest point release, 7.1 machines stay at 7.1. (I do not have any 
SL7 to compare)

So I am puzzled by all this. Maybe I should ask google: "is centos7 supposed to 
self update to latest point release?"


Then I takes quite a bit of work to get automatic updates to work at all on 
CentOS7
(CERN el7 seems to be okey):

a) The yum.cron package is crazy - each time I need to use yum, I have to wait
until it finishes some useless background tasks. Then "yum remove yum.cron" has
no effect because all the cron jobs are part of the main yum package. Go figure.

b) the CERN yum-autoupdate package, which we use for SL6 updates, depends
on a yum plugin not available anywhere (except from a CERN repo) and then 
actually
does not work out of the box because of strange interaction with systemd - only 
works after a reboot.

bb) then it does not send any email about updates - the el6 yum-autoupdate did 
this,
where did this function go?!?

(Hmm... maybe I should try these auto update scripts from the SL7 repository?)


So as they say, 1 step forward, 2 steps back.


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: a year later - CERN move to Centos - what are we doing?

[Ken Teh]

The kickstart disk partitioning tool is even dumber than they new GUI tool,
only useful for "one-size-fits-all" cases where you also do not mind 
accidentally
deleting the contents of all disks. (yes, open the machine, disconnect disks,
install, reconnect disks, close the machine, thanks, but no thanks).




I've started using the disk-by-id option in my kickstarts to target
specific disks in disk/fs related directives.  A tip I got from Nico who
suggested I use the %pre section to configure the disks exactly the way
I want to.  Works really well.  My %pre even contains commands to reset
the LVM on re-installs.

Many thanks, Nico!

Ken

Re: a year later - CERN move to Centos - what are we doing?

[Yasha Karant]

For the immediate future, we plan to continue with SL 7.  When EL 8 
emerges, we may need to re-evaluate the situation.  That being stated, 
for non-CERN groups (that is, groups neither employed by CERN nor in one 
of the collider collaborations), is there a CERN equivalent to this SL list?
What "services" does linux.supp...@cern.ch provide?  I understand that 
for CERN groups, the service presumably is close to what RH provides to 
contract for-fee customers, with the proviso that the CS persons with 
CERN groups know what they are doing.  What is available to non-CERN 
groups/persons?  If this is information that is not relevant to the 
entire SL list, a private email would be appreciated.


On 01/13/2016 09:24 PM, Jaroslaw Polok wrote:
If you use CERN CentOS 7 - please contact us at linux.supp...@cern.ch 
in case you encounter problems, if you use CentOS 7 - please use centos

mailing lists...



Now CERN Linux el7 comes in and I see the machines installed as 7.1 
stay there,

no automatic update to 7.2. Odd.

Then here, I see same with CentOS7 - no automatic updates by default, 
no automatic
updates to latest point release, 7.1 machines stay at 7.1. (I do not 
have any SL7 to compare)


So I am puzzled by all this. Maybe I should ask google: "is centos7 
supposed to self update to latest point release?"


In both cases you should get automatic updates to latest release 
(while using default yum repository definitions), if this is not the 
case: please report the problem.





Then I takes quite a bit of work to get automatic updates to work at 
all on CentOS7

(CERN el7 seems to be okey):

a) The yum.cron package is crazy - each time I need to use yum, I 
have to wait
until it finishes some useless background tasks. Then "yum remove 
yum.cron" has
no effect because all the cron jobs are part of the main yum package. 
Go figure.


b) the CERN yum-autoupdate package, which we use for SL6 updates, 
depends
on a yum plugin not available anywhere (except from a CERN repo) and 
then actually
does not work out of the box because of strange interaction with 
systemd - only works after a reboot.


bb) then it does not send any email about updates - the el6 
yum-autoupdate did this,

where did this function go?!?


again: if you encounter such problem(s) - please report.



(Hmm... maybe I should try these auto update scripts from the SL7 
repository?)



So as they say, 1 step forward, 2 steps back.




... I think this discussion went totally off-topic for the SL mailing 
list ..


Best Regards

Jarek

Re: a year later - CERN move to Centos - what are we doing?

[Jaroslaw Polok]

If you use CERN CentOS 7 - please contact us at linux.supp...@cern.ch in 
case you encounter problems, if you use CentOS 7 - please use centos

mailing lists...



Now CERN Linux el7 comes in and I see the machines installed as 7.1 stay there,
no automatic update to 7.2. Odd.

Then here, I see same with CentOS7 - no automatic updates by default, no 
automatic
updates to latest point release, 7.1 machines stay at 7.1. (I do not have any 
SL7 to compare)

So I am puzzled by all this. Maybe I should ask google: "is centos7 supposed to self 
update to latest point release?"


In both cases you should get automatic updates to latest release (while 
using default yum repository definitions), if this is not the case: 
please report the problem.





Then I takes quite a bit of work to get automatic updates to work at all on 
CentOS7
(CERN el7 seems to be okey):

a) The yum.cron package is crazy - each time I need to use yum, I have to wait
until it finishes some useless background tasks. Then "yum remove yum.cron" has
no effect because all the cron jobs are part of the main yum package. Go figure.

b) the CERN yum-autoupdate package, which we use for SL6 updates, depends
on a yum plugin not available anywhere (except from a CERN repo) and then 
actually
does not work out of the box because of strange interaction with systemd - only 
works after a reboot.

bb) then it does not send any email about updates - the el6 yum-autoupdate did 
this,
where did this function go?!?


again: if you encounter such problem(s) - please report.



(Hmm... maybe I should try these auto update scripts from the SL7 repository?)


So as they say, 1 step forward, 2 steps back.




... I think this discussion went totally off-topic for the SL mailing 
list ..


Best Regards

Jarek

Re: Dell Precision T1700 default xorg.conf file needed

[Yasha Karant]

On 01/13/2016 07:53 AM, Mark Stodola wrote:

On 01/13/2016 01:35 AM, Yasha Karant wrote:

On 01/11/2016 08:52 AM, Akemi Yagi wrote:

On Mon, Jan 11, 2016 at 8:43 AM, Mark Stodola > wrote:

On 01/11/2016 09:57 AM, Yasha Karant wrote:

On 01/09/2016 04:37 PM, Akemi Yagi wrote:


If you are sure the xorg.conf file existed but has been
removed with
no backup, then it was not done by ELRepo. I suggest you
look into the
code. You will find that ELRepo's package would not remove
xorg.conf
without backing up.


I respectfully disagree.  It is possible that there were 
multiple

installs/updates of the ELRepo driver during the experimental
stages of
getting
SL 7 to work on the platform as the platform was delivered.
But -- both
the primary and backup copies have an ElRepo comment and no
"stock"
content.  Because of the way the Dell boot bios interacted
with the
platform after a power outage (beyond the limits of the 
small UPS

attached to the unit -- that may need new batteries but the
Department
may not have the money to maintain), the only way to get to
the obvious
Dell boot configuration screen (GUI driven) was to remove the
Nvidia
card -- and the system does now boot to the text terminal
interface, but
no GUI.

I can email to you the xorg.conf files I found on the machine
after the
above actions.  I will do additional digging. Meanwhile, no
one has
responded so I either will find the X11 xorg configuration
utility or
attempt to copy one from a working machine that has no Nvidia
card.

Yasha


I haven't had much time to work with SL7 yet, but isn't it the
case that there is no xorg.conf by default?  Try just renaming the
nvidia generated one and see what happens.  I think the X server
attempts to autodetect settings, which has gotten fairly reliable
over the years for the most common setups.

-Mark


That is my understanding. In SL7, there should be no xorg.cong file by
default. In fact, |xorg.conf| is marked as deprecated in EL6, but will
still be used if it is present. Graphical settings are supposed to be
automatically detected and configured by the X server.

Akemi


Precisely the problem.  The Nvidia X11 driver package seems to have
"hardwired" some version of the Nvidia (not noveau) driver into the
system.  How does one find this and revert to "stock"  for an Intel
graphics driver or for some more generic VGA style driver?   If I list
the installed RPMs and remove the Nvidia RPM will this address the 
issue?


My laptop (upon which I am now working) has a laptop Nvidia "card". 
Thus,


rpm -qa reveals

nvidia-x11-drv-352.41-1.el7.elrepo.x86_64

when I do the same on the workstation in question, I presume I will find
a similar (but perhaps different numbered) nvidia-*-el7.elrepo.x86_64;
if I rpm -e the version on the workstation, will this action force a
return to "default/stock" or must I do something in addition?

Yasha Karant



Uninstalling both the kmod-nvidia and the nvidia-x11-drv should do the 
trick.  It may leave behind the xorg.conf for you to manually remove, 
depending on how the rpm was configured during build.


It is the kmod-nvidia module which does the nouveau blacklisting using 
/usr/lib/modprobe.d/blacklist-nouveau.conf.


-Mark

Mark,

You were correct.  After removal of the Nvidia PCI add-on card, and thus 
getting to a scrolling terminal screen (ctrl-alt-F2, etc.), login as root,
rpm -qa | grep elrepo , yielded the two packages.  yum -remove one of 
the packages (after a long wait to check many repositories) removed both 
packages (the other as a dependency), reboot, clean X11 GUI login.   
Thanks for the hint.  Presumably, in a future iteration of the elrepo 
packages, there will be an automagic test to verify that a Nvidia board 
really is present, and, if not, use the stock driver as if no elrepo 
Nvidia package had been installed.


Yasha

Re: a year later - CERN move to Centos - what are we doing?

[Steven Haigh]

On 2016-01-14 07:45, jdow wrote:

There is at least one other sub group around here who value generally
quiet sober support when they have a problem. Ubuntu and many other
distros are quality distros, and perhaps better support what some
people want. But the Ubuntu and Fedora mailing lists and support are
unbelievably noisy and getting help often (usually?)requires
rhinoceros hide and extreme persistence. This very mailing list which
is getting defiled by this pointless discussion is what I value about
SL. This list is mercifully seldom sullied by trolls. And the SL
distro itself is competent and has what I need, a few smart people
supporting me on the mailing list and reasonably timely updates. So,
every time I even think of moving I slap myself across the face and go
do something important.

{^_^}   Joanne


^^ this. I seldom post to the -users list - as most of my stuff is more 
related to the -devel list.


That being said, I'm glad I don't get 200 emails a day through this 
list, and would be happy to see the off topic drivel stop so we can go 
back to focussing on actual problems - not constructed problems about a 
false understanding of lack of choice.


--
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897

Re: a year later - CERN move to Centos - what are we doing?

[Karel Lang AFD]

Lejeczek, Iosif etc,
I really dunno, what you guys wanna hear?

you come and say you switch/switched to centos - and you ask for what? 
for blessing? :D well ... i bless you :D


Now, joking aside, Fermilab said clearly they go with SL7x and they do.
And while you will have supp for sl/rhel 6x roughly to 2020, that makes 
sl/rhel 7x to roughly 2025? this is enough for me


without detail, why i prefer sl is
-small friendly community, incl. friendly devs
-updates
-i feel more independent to rh as far as possible, considering it is 
rhel clone


Again, what you trying to say? That we have here at list some ppl (me?) 
stuck on SL and saw no other distros? haha :D i go with linux since 1997..


--
*Karel Lang*
*Unix/Linux Administration*
l...@afd.cz | +420 731 13 40 40
AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz

On 01/13/2016 11:43 AM, lejeczek wrote:

I think we see two groups of people here, taking part in this "exciting"
debate.

One is, people who genuinely try to learn a bit about more concrete
plans Fermilab have(or don't have) for the future of Scientificlinux -
and they do it here on the list because they can sroogle all over the
Net and they won't find any solid, ideally rendered by the very source
itself statement.

The second group is people who don't give a toss, a good chance is it's
because they have not seen much beside Scientificlinux and they really
believe it's very unique indeed. You can see scientist type of mentality
here -- I have got my one little or big app, it runs great! and I'm
happy with it and I can say I do it all on by myself cause I do not have
to deal with any commercial third entities (which is very important for
a scientist) -- very simplistic and egotistic attitude, but works. And a
good chance is this bunch don't have to even ask about bigger picture.
Some individuals from this group can even be rude and hostile towards
others, even if only asked about sharing a thought or two on the issue.

Well, like esteemed fellows already said - we're free to do as we wish,
fortunately, only unfortunate is that we cannot always make fully
informed decisions. I guess that's science, that's life. Heh. :)
b.w.



On 13/01/16 10:13, Iosif Fettich wrote:

Hi there,


anyone who wants to go with centos, is free to do so, right? So just
go and do it and don't 'fuss' about it on SL mail list.


Thanks for the nice advice.

Would you have another one too? On which list should current SL users
ask/discuss about the short/long term plans regarding SL? And/or of
the problems related with a migration from/to SL?


We all should be grateful for continuing support of Fermilab for SL
builds.


That's something we most probably all on this list agree with
unconditionally.

Thank you,

Iosif Fettich

---
Iosif Fettich | e-mail: ifett...@netsoft.ro   phone+fax: +40-265-260256
Gen. Manager  | web:http://www.netsoft.ro phone: +40-365-806800
NetSoft SRL   | GPGkey: http://www.netsoft.ro/ifettich/public_gpg_key

Re: Dell Precision T1700 default xorg.conf file needed

[Mark Stodola]

On 01/13/2016 01:35 AM, Yasha Karant wrote:

On 01/11/2016 08:52 AM, Akemi Yagi wrote:

On Mon, Jan 11, 2016 at 8:43 AM, Mark Stodola > wrote:

On 01/11/2016 09:57 AM, Yasha Karant wrote:

On 01/09/2016 04:37 PM, Akemi Yagi wrote:


If you are sure the xorg.conf file existed but has been
removed with
no backup, then it was not done by ELRepo. I suggest you
look into the
code. You will find that ELRepo's package would not remove
xorg.conf
without backing up.


I respectfully disagree.  It is possible that there were multiple
installs/updates of the ELRepo driver during the experimental
stages of
getting
SL 7 to work on the platform as the platform was delivered.
But -- both
the primary and backup copies have an ElRepo comment and no
"stock"
content.  Because of the way the Dell boot bios interacted
with the
platform after a power outage (beyond the limits of the small UPS
attached to the unit -- that may need new batteries but the
Department
may not have the money to maintain), the only way to get to
the obvious
Dell boot configuration screen (GUI driven) was to remove the
Nvidia
card -- and the system does now boot to the text terminal
interface, but
no GUI.

I can email to you the xorg.conf files I found on the machine
after the
above actions.  I will do additional digging. Meanwhile, no
one has
responded so I either will find the X11 xorg configuration
utility or
attempt to copy one from a working machine that has no Nvidia
card.

Yasha


I haven't had much time to work with SL7 yet, but isn't it the
case that there is no xorg.conf by default?  Try just renaming the
nvidia generated one and see what happens.  I think the X server
attempts to autodetect settings, which has gotten fairly reliable
over the years for the most common setups.

-Mark


That is my understanding. In SL7, there should be no xorg.cong file by
default. In fact, |xorg.conf| is marked as deprecated in EL6, but will
still be used if it is present. Graphical settings are supposed to be
automatically detected and configured by the X server.

Akemi


Precisely the problem.  The Nvidia X11 driver package seems to have
"hardwired" some version of the Nvidia (not noveau) driver into the
system.  How does one find this and revert to "stock"  for an Intel
graphics driver or for some more generic VGA style driver?   If I list
the installed RPMs and remove the Nvidia RPM will this address the issue?

My laptop (upon which I am now working) has a laptop Nvidia "card". Thus,

rpm -qa reveals

nvidia-x11-drv-352.41-1.el7.elrepo.x86_64

when I do the same on the workstation in question, I presume I will find
a similar (but perhaps different numbered) nvidia-*-el7.elrepo.x86_64;
if I rpm -e the version on the workstation, will this action force a
return to "default/stock" or must I do something in addition?

Yasha Karant



Uninstalling both the kmod-nvidia and the nvidia-x11-drv should do the 
trick.  It may leave behind the xorg.conf for you to manually remove, 
depending on how the rpm was configured during build.


It is the kmod-nvidia module which does the nouveau blacklisting using 
/usr/lib/modprobe.d/blacklist-nouveau.conf.


-Mark

Re: a year later - CERN move to Centos - what are we doing?

[Jim Campbell]

On Tue, Jan 12, 2016, at 05:43 PM, Konstantin Olchanski wrote:
> On Tue, Jan 12, 2016 at 09:48:23AM +, lejeczek wrote:
> >
> > I personally am just about to trial a migration from SL7 to Centos.
> > I'm thinking it's inevitable, am I wrong?
> > 
> 
> I tried both SL7 and CentOS7 (and I have CC7 machines running at CERN).
> 
> The installer for both have the same idiotic "you *must* create a fake
> user or no login prompt for you!",
> and the same "you *must* use the disk partition tool designed by dummies
> for dummies".
> 
> So no practical difference at installation. Both installers boot from USB
> flash,
> no need to engrave the ISO images into stone tablets (an improvement over
> SL6).
> 
> After installation, I do not have to setup a local mirror for CentOS7
> repositories - CentOS7 automatically
> finds and downloads all packages from the very super fast mirror at
> SFU.ca. This is
> compared to SL7 which very-very-very-very-very-very slowly slowly slowly
> downloads all packages from Fermilab.
> 
> So one difference there.

Others have covered some of the points here. With regards to the mirrors
and download speed, it seems that CentOS installs the yum-fastestmirror
package by default, while perhaps Scientific Linux does not. I don't
really see this as a big issue for SL, though. If you install the
yum-fastestmirror package, you won't default to downloading from the
Fermilab repositories.

There are a good number of SL mirrors available, too, so I don't want
people to think of package download speed as some kind of disadvantage
for SL.

As I understand it, one of the key values of SL is that it allows you to
stay on a point release and obtain only security fixes for your packages
(someone else mentioned this, too). This is important when running
scientific experiments where you can't allow changes in software to
impact your research results. Unless something has changed, neither
CentOS nor the North American Upstream Vendor provide this service. This
feature from Scientific Linux is a valuable one if you need it.

Jim