Hi Fotis,
I just wanted to query the SL*4 has "*less-than-desired patch-level*" SL4.9
will get security updates until Feb 2012 - glite-Mon and lcg-CE should
certainly be end of life before then.
Is it that much trouble to keep a few legacy service running?
Yours,
Chris.
On 02/03/2010 09:43, "Fotis Georgatos" <[log in to unmask]> wrote:
> Dear all,
>
> brief picture:
> * SAM depends on lcg-CE and MON services, so let's call these "grid-required"
> * lcg-CE and glite-MON targets are officially supported only under gLite v3.1
> * gLite v3.1 requires SL*4 OS, which has *less-than-desired patch-level*
>
> I have used these two urls as my reference for the previous statements:
> http://glite.web.cern.ch/glite/packages/R3.1/
> http://glite.web.cern.ch/glite/packages/R3.2/
>
> But the following, seems to suggest that some related work is ongoing:
> "Some libraries have been added to LD_LIBRARY_PATH and ld.so.conf to be able
> to configure lcg CE and cream CE in SL5." (found in lcg-CE v3.1.39-0 notes)
> http://glite.web.cern.ch/glite/packages/R3.1/deployment/lcg-CE/3.1.39-0/lcg-CE
> -3.1.39-0-update.html
>
> So,
> are there going to be glite v3.2 updates for lcg-CE and MON packages?
> OR,
> could we have a compatibility statement for those i386 binaries under 64bit?
>
> I take the opportunity to ask the following two CEs (w. el5/64bit lcg-CEs?),
> their real-world experience: pg.ihepa.ufl.edu & ceprod00.hep.ph.ic.ac.uk
> At least the 2nd one, really looks quite like lcg-CE on el5/64bits.
> (if someone could pass on the message, please do so)
>
> ps.
> Check below for some proof of the previous claims for unpatched OS situation.
> (debugging these problems takes *hours* on our behalf, I hope we can avoid it)
>
> ps2.
> I'd like to hear by other people what is the "supported" configuration for
> running together lcg-CE and CREAM CE (including lrms, what and how exactly),
> AFAI can tell, many sites have had troubles in getting this forward so,
> if someone can provide a URL with real-world experience it would be so nice!
>
> tia,
> Fotis
>
> ===
>
>
> (this part is only fyi and is only addressing fellow sysadmins)
>
> SL*4 is less than supported, with some OS packages being old versions;
> this seems to apply for both i386 and x86_64 versions.
> eg. look at: http://linuxsoft.cern.ch/cern/slc4X/i386/yum/updates
> If the fault lies in the upstream RHEL4, I think it is not an excuse!
>
> As an example, the xargs command as it is supplied and running right *now*
> (as of March 2010) in nearly any lcg-CE, is a well-known problematic version,
> and the current rpm findutils-4.1.20-7.el4.3 didn't get any yum update,
> for a couple of years already.
>
> I'll spare you the details, but just provide an one-liner that annoyed us:
> (in the 1st case it will spawn only 2 out of 5 children processes)
>
> [root@ce01 ~]# echo wn08 wn10 wn16 wn21 wn45|xargs -n1|xargs -n1 --replace
> strace ssh {} uptime 2>&1 |grep '"wn'
> execve("/usr/bin/ssh", ["ssh", "wn08", "uptime"], [/* 69 vars */]) = 0
> read(4, "wn16\nwn21\nwn45\n", 16384) = 15
> execve("/usr/bin/ssh", ["ssh", "wn10", "uptime"], [/* 69 vars */]) = 0
> [root@ce01 ~]#
> [root@ce01 ~]# xargs --version
> GNU xargs version 4.1.20
> [root@ce01 ~]#
> [root@ce01 ~]#
>
> # Let's use now a locally recompiled from latest sources binary
>
> [root@ce01 ~]# echo wn08 wn10 wn16 wn21 wn45|xargs -n1|
> /root/fotis/xargs/findutils-4.4.2/xargs/xargs -n1 --replace strace ssh {}
> uptime 2>&1 |grep '"wn'
> execve("/usr/bin/ssh", ["ssh", "wn08", "uptime"], [/* 69 vars */]) = 0
> execve("/usr/bin/ssh", ["ssh", "wn10", "uptime"], [/* 69 vars */]) = 0
> execve("/usr/bin/ssh", ["ssh", "wn16", "uptime"], [/* 69 vars */]) = 0
> execve("/usr/bin/ssh", ["ssh", "wn21", "uptime"], [/* 69 vars */]) = 0
> execve("/usr/bin/ssh", ["ssh", "wn45", "uptime"], [/* 69 vars */]) = 0
> [root@ce01 ~]#
> [root@ce01 ~]# /root/fotis/xargs/findutils-4.4.2/xargs/xargs --version
> xargs (GNU findutils) 4.4.2
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by Eric B. Decker, James Youngman, and Kevin Dalley.
> Built using GNU gnulib version e5573b1bad88bfabcda181b9e0125fb0c52b7d3b
> [root@ce01 ~]#
>
> (I can also verify that the bug does not seem to manifest itself under sl*5)
>
> btw.
> some statistics about findutils rpms on CEs available for dteam VO:
> [gef@ui01 ~]$ sort /tmp/xargs_rpm_versions|uniq -c
> 5 findutils-4.1.20-7.el4.1
> 1 findutils-4.1.20-7.el4.1.x86_64
> 283 findutils-4.1.20-7.el4.3
> 11 findutils-4.1.20-7.el4.3.i386
> 51 findutils-4.1.20-7.el4.3.x86_64
> 2 findutils-4.1.7-9
> 6 findutils-4.1.7-9.1.SL
> 2 findutils-4.2.27-6.el5
> [gef@ui01 ~]$
>
> btw-and-fyi: The offending command to collect the above info had been:
> time cat CEs |xargs -P33 -n1 --replace globus-job-run {} -m 5 /bin/rpm -qf
> /usr/bin/xargs|tee /tmp/xargs_rpm_versions
>
> The 2 sites with a patched findutils-4.2.27-6.el5, run on a rhel5 variant!
|