Re: bash-update
Excerpts from Werf, C.G. van der (Carel)'s message of 2014-09-25 11:16:35 +0200: Yesterday a lot of yum-updates ran to update to the latest bash-versions. Though my /bin/bash was changed last night, and yum.log shows 3.2.33 should have installed, # /bin/bash --version still shows 3.2.25 Ofcourse, also # strings /bin/bash shows old version number. Is this a policy NOT to change version-numbers ? The version of bash has not changed. Only the release number. i.e additional patches ontop of bash version 3.2.25. Run rpm -q --changelog bash | less should give a clue as to patches being applied Steve Regards, Carel -- -- Steve Traylen, CERN IT.
Re: [SCIENTIFIC-LINUX-USERS] News on Scientific Linux
Excerpts from Pat Riehecky's message of 2014-06-06 16:20:35 +0200: The folks over at CentOS are planning to host the RHEL source in a set of git repos. The long term future of source rpms on ftp.redhat.com is somewhat fluid right now. https://indico.cern.ch/event/274555/session/11/#20140519 has some SL related presentations from last week. Steve Pat On 06/06/2014 09:14 AM, Peter C. Chiu wrote: An indirect news from a colleague, hence I am seeking for more creditable clarification from this group. -Original Message- From: Stephen Berg (Contractor) [mailto:stephen.berg@nrlssc.navy.mil] Sent: 06 June 2014 15:11 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Re: News on Scientific Linux On 06/06/2014 09:08 AM, peter.c...@stfc.ac.uk wrote: I have heard of some rather upsetting news that Scientific Linux will likely to be dropped soon as RHEL aren't planning to release source rpms outside the RHEL customers - only source tar balls. Not sure if the change on source makes any difference to the Sc Linux development team. But I shall be grateful if someone please confirm or deny this news. Many thanks. Peter What's your source for that information? -- Stephen Berg Systems Administrator NRL Code: 7320 Office: 228-688-5738 stephen.berg@nrlssc.navy.mil -- -- Steve Traylen, CERN IT.
Re: aufs rpm
Excerpts from n.chandra sekhar's message of 2014-05-07 16:33:36 +0200: In that list there is no rpm which supports for the required kernel ( 2.6.32-358.11.1.e16.x86_64) They are not kernel modules for a default SL running kernel. They are complete kernels that support aufs. Steve. On Wed, May 7, 2014 at 4:53 PM, David Sommerseth sl+us...@lists.topphemmelig.net wrote: On 07/05/14 13:12, n.chandra sekhar wrote: Hi I am using scientific Linux 6 of kernel version is 2.6.32-358.11.1.e16.x86_64 , so can body suggest where i can i get the aufs rpm for this kernel version or if anyone knows please provide the downlaod link Please see the response you already got here: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1405L=scientific-linux-usersT=0P=1444 -- kind regards, David Sommerseth -- -- Steve Traylen, CERN IT.
Re: Building RPMs for EL
Good Afternoon, I have a couple of questions about how portable code built on various EL's is between OS's/versions. If I build an RPM on SL6.1 from an arbitrary SRPM that has not been specifically targeted for EL6, has no distribution-specific, version-specific or renamed dependancies, how portable can I expect it to be? Would I just be able to drop it onto a CentOS6.2 or TUV6.0 system, for example, and have it just work. Assuming the answer is no: * What steps/build settings/macros are needed to make it cross-version portable (SL 6.1, 6.0, 6.n)? * What steps/build settings/macros are needed to make it cross-distribution compatible (SL, CentOS, TUV, etc.)? The answer should be yes though within any of the above 6.x. There might be exceptions but in thatcase in principal they should be fixed. In particular there should ne no so bumps with a 6 release. More over if you build something on e.g Centos N.x itshould run with out rebuild on thenext major release, e.g SL N+1.x. This is what the compat packages are for. Thanks, Adam Bishop JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG
Re: upstart
On Feb 3, 2012, at 8:08 PM, Yasha Karant wrote: have been looking into the issue of upstart. From: http://upstart.ubuntu.com/ Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. and is therein listed as: Known Users Ubuntu 6.10 and later Fedora 9 and later This is wrong. Fedora 15 and up uses systemd. http://www.freedesktop.org/wiki/Software/systemd with compatibly for SysV stuff present. Fedora is pushing hard to convert everything to systemd for Fedora17 and they did for 16 as well. One can assume form that RHEL7 will land with systemd. Steve. Debian (as an option) Nokia's Maemo platform Palm's WebOS Google's Chromium OS Google's Chrome OS
Re: comparison of packages on different repositories
On 12/14/2011 02:51 PM, Konstantin Olchanski wrote: On Wed, Dec 14, 2011 at 01:34:50PM -0800, Yasha Karant wrote: A partial list that I have found includes ElRepo.org, PUIAS, ATrpms, RPMforge.net, Extra Packages for Enterprise/EPEL, and of course SL 6 itself ... Please add SLC 6, the CERN flavour of SL. Contains many additional packages, some only useful at CERN, others generally useful, but avialable only to users inside CERN. If SLC 6 only is available to users inside CERN (presumably anyone with a CERN account that can use the repository through a connection -- possibly a VLAN tunnel -- to onsite CERN) but not to those of us who are not inside CERN -- it seems to me that the repository is of little use except to those at CERN. I do repost my question: how does one compare the various repositories? Note that EPEL states: Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL). EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more. End quote. Thus, EPEL claims that EPEL packages will never conflict with or replace packages in the base Enterprise Linux distributions. If this claim is factual, then one presumably can mix EPEL and SL packages (for the same release and architecture) without concern. I am attempting to discover if this sort of a claim is true for any other of the public repositories. Take a look here, http://iuscommunity.org/Docs/SafeRepoInitiative was an attempt to define such a safe repository. Epel and Sl , its almostvtrue but there have been exceptions, e.g Sl has icewm as an addition but epel just added it in the last week or so. Yasha Karant
Re: Please consider addition of gnuplot42
any comment? On Fri, Mar 19, 2010 at 11:59 AM, Steve Traylen steve.tray...@cern.ch wrote: Hi, I've users who wish to have gnuplot42 on SL5 (and4) These are some packages here I've done: http://cern.ch/straylen/rpms/gnuplot42/ which are designed to not interfere with the existing gnuplot packages present in SL4/5. I do have an open review here for EPEL: https://bugzilla.redhat.com/show_bug.cgi?id=570318 but due to lack of interest I guess it is not progressing. If it does progress I'll bump to higher release version in EPEL than in SL and advise SL of its redundancy in SL. Please consider gnuplot42 inclusion into SL. Steve -- Steve Traylen -- Steve Traylen
Re: Please consider addition of gnuplot42
On Thu, Mar 25, 2010 at 8:36 PM, Troy Dawson daw...@fnal.gov wrote: OK, first problem. This requires wxGTK, which is not in Scientific Linux. Is that an important part? Can it be removed as a dependancy? Do we want to also put that into SL? Doh, I never thought to check that it actually built on SL without EPEL. Will get back to you. Troy Troy J Dawson wrote: Hi Steve, Sorry for not getting back to this. I think it looks ok. I am goign to put it into contrib first. For SL5 I think we can get it into the full release. For SL4, I'd rather not. I'd rather leave it in the contrib area. SL4 at *some* point is going to go into legacy mode, and I'd like to keep the added packages down. Troy Steve Traylen wrote: any comment? On Fri, Mar 19, 2010 at 11:59 AM, Steve Traylen steve.tray...@cern.ch wrote: Hi, I've users who wish to have gnuplot42 on SL5 (and4) These are some packages here I've done: http://cern.ch/straylen/rpms/gnuplot42/ which are designed to not interfere with the existing gnuplot packages present in SL4/5. I do have an open review here for EPEL: https://bugzilla.redhat.com/show_bug.cgi?id=570318 but due to lack of interest I guess it is not progressing. If it does progress I'll bump to higher release version in EPEL than in SL and advise SL of its redundancy in SL. Please consider gnuplot42 inclusion into SL. Steve -- Steve Traylen -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __ -- Steve Traylen
Re: No, yum, gcc43 not gcc44
On Fri, Mar 19, 2010 at 8:47 PM, Brett Viren bvi...@minos.phy.bnl.gov wrote: This is probably a FAQ but I couldn't find the answer. I want to install gcc43 packages on SL 5.3 64bit so I do: yum install gcc43 gcc43-c++ gcc43-gfortran But yum ignores my command and says that gcc43 is obsoleted by gcc44 and instead installs gcc44! Complete insolence. How can I tell yum to actually do what I tell it to do? You could do it by telling yum to ignore the gcc44 packages. exclude=gcc44 in your yum.conf but its probably worth mentioning that gcc43 is no longer present upstream so there will of course be no updates for it. Thanks, -Brett. -- Steve Traylen
Please consider addition of gnuplot42
Hi, I've users who wish to have gnuplot42 on SL5 (and4) These are some packages here I've done: http://cern.ch/straylen/rpms/gnuplot42/ which are designed to not interfere with the existing gnuplot packages present in SL4/5. I do have an open review here for EPEL: https://bugzilla.redhat.com/show_bug.cgi?id=570318 but due to lack of interest I guess it is not progressing. If it does progress I'll bump to higher release version in EPEL than in SL and advise SL of its redundancy in SL. Please consider gnuplot42 inclusion into SL. Steve -- Steve Traylen
Re: TESTING - rrdtool for SL4 and SL5
On 2/1/10 4:27 PM, Ewan Mac Mahon wrote: On Thu, Dec 10, 2009 at 09:12:56AM -0600, Troy Dawson wrote: 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) This seems to cause rather bad breakage with the EPEL builds of ganglia, and possibly anything else that uses the rrdtool libraries. The current EPEL ganglia links against librrd.so.2, which is in the EPEL build of rrdtool as a symlink in the usual manner: # ls -l /usr/lib64/librrd.so.2 lrwxrwxrwx 1 root root 16 Feb 1 14:52 /usr/lib64/librrd.so.2 - librrd.so.2.0.13 The new SL rrdtool packages however, have a different library soname: # ls -l /usr/lib64/librrd.so.4 lrwxrwxrwx 1 root root 15 Feb 1 15:14 /usr/lib64/librrd.so.4 - librrd.so.4.0.8 Depending on the installation order, this either makes it impossible to install EPEL's ganglia (if the SL rrdtool is already installed) or to update from the sl-security repo if the EPEL rrdtool and ganglia packages are already installed. Given the reference to making the SL packages 'compatible with both epel and dag', I'm guessing this is not intended behaviour. I'm not sure how best to fix this, but the simplest approach may be to pull ganglia into SL and rebuild it against the newer rrdtool. Would it not be easier to just remove rrdtool from SL. Following on from fixing this way you would eventually have to replace everything in EPEL. Ewan
Re: OpenSSL 1.x
On Jan 28, 2010, at 9:15 PM, P. Larry Nelson wrote: Hi Troy, Troy Dawson wrote on 1/28/2010 1:55 PM: P. Larry Nelson wrote: Hi, I just received a HIGH criticality email from secur...@opensciencegrid.org stating: Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the certificate authentication for OSG/VDT. Not having my ear to the ground vis-a-vis openssl, does anyone know if that version is due to be released soon? Will it come from TUV or directly from openssl.org? (Troy/Connie question) Right now, we have openssl-0.9.8e-12.el5_4.1. I suppose the thing to do is to go and edit the yum.cron.excludes on all our OSG nodes to block openssl* until this issue is fixed. [sigh...] - Larry Scientific Linux, and RHEL are enterprise linux distributions. This means that they do *not* just update to the latest versions of packages. RedHat and SL will *not* just update to the latest version of openssl, just because it was released. SL 4.0 had openssl 0.9.7a SL 4.8 has openssl 0.9.7a Thas is after five years, we still have the same version of openssl. RedHat backports all the security fixes into the 0.9.7a version for RHEL4 (and hense SL4). SL 5.0 had openssl 0.9.8b SL 5.4 has openssl 0.9.8e Even SL6 won't have openssl 1. It was only added after FC12 that SL6 will eventually be based on. Steve After 3 years, SL5 is still at version 0.9.8, although we have moved from b to e. I cannot say for 100% certain, because we are not RedHat. But according to all their policies, goals, statements and past history, they are not going to move openssl above version 0.9.8 for RHEL 5 (and hense SL5) Troy Thanks for the info and history lesson. I didn't know and didn't want to assume. As far as I knew, openssl 1.x might have been a big hairy deal security fix that was imminent. - Larry -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | High Energy Physics Group 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ --- Information without accountability is just noise. - P.L. Nelson
Please can sqlite databases be generated also for SL5 RPM repositories?
Hi, Currently you must be running something along the lines of createrepo /linux/scientific/52/i386 to generate the YUM metadata? Please could you consider adding a '-d' option as well. createrepo -d /linux/scientific/52/i386 this creates all the existing meta data but also the sqlite files as well. The advantage of this is the subsequent yum queries are significantly faster. Clearly the same would have to be applied for all sl5x repositories to be sensible. The other reason is that the mergerepos script used by very recent versions of koji would then be able to make use of the SL repositories as an external repository. Unfortunately the -d option is not available in the sl4 version of createrepo nor does yum make any use of those files. For the koji reasons above though the sqlite data would be useful but clearly I understand why you may not want to do that. Many Thanks. Steve -- Steve_Traylen
Re: debugging a http based install
On Wed, Jul 2, 2008 at 10:19 PM, Ken Teh [EMAIL PROTECTED] wrote: I just started using the http based kickstart install. Done via the kickstart url option. I have installed a couple of SL5.1 systems successfully and tried today to install a SL4.6 machine. I boot the system with the disc1 iso image and provide the kickstart file via NFS. Like so: boot: linux ks=nfs:installserver.my.net:/SL/46/ks/myks In my kickstart file I specify our local SL mirror as the install server. Like so: url --url http://mirror.anl.gov/pub/scientific-linux/46/i386 Hi Ken, $ curl http://mirror.anl.gov/pub/scientific-linux/46/i386 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title301 Moved Permanently/title /headbody h1Moved Permanently/h1 pThe document has moved a href=http://mirror.anl.gov/pub/scientific-linux/46/i386/;here/a./p hr addressApache Server at mirror.anl.gov Port 80/address /body/html so try adding the / on the end. RPM at least does not follow these , I don't know about the internals of anaconda. Steve Works for 5.1 but not for 4.6. I've attached the Alt-F2 screen. Can someone provide some pointer on how to debug this? How do I go about isolating the problem? I can revert back to using my old method which is an NFS based install. But http based installs are so convenient especially since we have high-speed access to a local SL mirror. Thanks! -- Steve Traylen
Re: Broken SL5 RPM tclx-8.4.0-5.fc6
2008/5/12 Shane Voss [EMAIL PROTECTED]: The RPM for tclx-8.4.0-5.fc6 seems to me to be broken. The RPM delivers /usr/lib/tclx8.4/ which contains a bunch of .tcl files, and also libtclx8.4.so It runs ldconfig after install, but this won't find the .so file. Hi Shane, Not sure what it is you want to do but does installing the tclx-devel package help. Steve I think the .so should be put in to /usr/lib This is how the tcl RPM behaves. [The 64 bit version treats /usr/lib64 in the same fashion] Am I missing something? Shane -- Shane Voss, Computing Officer, School of GeoSciences, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Steve Traylen
Re: rpm won't play nice
On Mar 28, 2008, at 4:57 PM, Faye Gibbins wrote: Hi, Having built lots of rpms I've never used the Requires: foo some release, RedHat RPM Guide, page 211. Today I added this: Requires: qt 4.0.0 to an rpm for QScintilla I was building and it doesn't work. Hi Faye, What does not work? Look at the rpms with $ rpm -q --provides qt $ rpm -qp --requires qsintilla Steve NB: snip--- [EMAIL PROTECTED] qsintilla $ rpm -q qt qt-3.3.6-23.el5 [EMAIL PROTECTED] qsintilla $ snip--- Has anyone else used this option on SL5? Does it work for you? Yours Faye -- - Faye Gibbins, Computing Officer (Infrastructure Services) GeoS KB; Linux, Unix, Security and Networks. Communications Technologist - IT Professionals' Forum Beekeeper - The Apiary Project, KB - www.bees.ed.ac.uk - I grabbed at spannungsbogen before I knew I wanted it. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Steve Traylen [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Need the default apache /etc/httpd conf files.
On Feb 28, 2008, at 9:16 AM, Faye Gibbins wrote: Hi, Can't you just rpm2cpio the relevant rpm then extract the files you need? There is also the rpm -Uvh --replacepkgs apachei386.rpm option. From the man page: --replacepkgs Install the packages even if some of them are already installed on this system. Or even install the apache rpm in a chroot then copy them across? Yours Faye Mark Tilles wrote: I recently installed SL 5.1 but accidentally erased /etc/httpd/ folder … da. Could someone who has this folder intact and unmodified please post this folder gzipped somewhere where I can download it? -- - Faye Gibbins, Computing Officer (Infrastructure Services) GeoS KB; Linux, Unix, Security and Networks; Communications Technologist - IT Professionals' Forum Beekeeper - The Apiary Project, KB - www.bees.ed.ac.uk - I grabbed at spannungsbogen before I knew I wanted it. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Steve Traylen [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: RHEL5 vs SL5 java compatibility issues
On Jan 15, 2008, at 8:33 PM, Tony Hoffmann wrote: I found that there are some compatibility issues between RHEL5 and SL5 in regards to how java 1.5.0 is being distributed. We have a beta astronomy package which depends on RedHat's java-1.5.0-sun (specifically it lists libjava.so as a requirement). Their repo does supply the required package, but yum removes the SL java-1.5.0- sun-compat as it conflicts with the Redhat packaging. I guess my question is why does SL use different packaging from the upstream vendor for java 1.5.0? I would avoid using SUN' s java rpm that are in the SL repo since they are broken for a number of reasons. One in particular is that they publish that they provide xml-commons-apis and in fact it do not. This then get removed by other packages in repository which do genuinly provide it. The JPackage version of java RPMS work significantly better. this page has some of the details https://twiki.cern.ch/twiki/bin/view/EGEE/GLite31JPackage . It details SL4 but is the same for SL5. or just use Jpackage instructions them selves. If you look in google that are lots of threads about why SUNs Java Package is not very good. Steve -- Tony Hoffmann | Tel: (250)493-2277 | Fax: (250)493-7767 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] National Research Council Canada | P.O. Box 248, Penticton BC V2A 6J9 Conseil national de recherches Canada | B.P. 248, Penticton (C.-B.) V2A6J9 Government of Canada | Gouvernement du Canada -- Steve Traylen [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Security ERRATA for firefox on SL5.x, SL4.x, SL3,x i386/x86_64
On Oct 23, 2007, at 12:08 PM, [EMAIL PROTECTED] wrote: On Fri, 19 Oct 2007, Troy Dawson wrote: SL 4.x x86_64: firefox-1.5.0.12-0.7.el4.i386.rpm firefox-1.5.0.12-0.7.el4.x86_64.rpm Hi, The above update to firefox.i386 on the x86_64 architecture has broken the acrobat and java plugins. (using acroread 7.0.9 and Sun Java 6u3) Clicking on a PDF file causes firefox to exit immediately and launching webpages that require a java plugin no longer works. If I revert to firefox-1.5.0.12-0.3.el4.i386 everything works as expected. The reason we're using the i386 version on an x86_64 arch is to get the various plugins working that have no x86_64 equivalent. I can get around the PDF issue by not using the plugin and just loading the file externally in xpdf/acroread but we need the java plugin to work too. Ronnie, Not a solution to your actual problem but: http://gwenole.beauchesne.info/projects/nspluginwrapper/ allows you to run 32bit plugins in a 64 bit firefox. Steve cheers, Ronnie -- Name: Dr Ronnie Wallace Institution: University of Strathclyde, Glasgow, Scotland Department: Mathematics -- Steve Traylen Work Calendar: http://tinyurl.com/22lw9o [EMAIL PROTECTED] CERN, IT-GD-OPS.
Re: torque vs sockets in 4.4
On Aug 7, 2007, at 4:56 AM, Miles O'Neal wrote: We recently migrated from PBS to torque, and most of our systems are now running 4.4 . The torque server (a Core2 Duo at 2.4GHz) is only handling about 3x the jobs our 300MHz Sun Ultra 5 could handle before bogging down horribly. This seems a bit odd. How many nodes and jobs? Watching the server logs, it seems there's a lot of time spent waiting for replies on sockets, though it's not clear whether it's on the same system between the scheduler and batch server, or between the batch server and client node processes (pbs_moms). Do consider changing the values as described here. http://www.clusterresources.com/torquedocs21/a.flargeclusters.shtml in particular for large farms you really need to have poll_jobs set to true and increase the job_stat_rate. We're beginning to wonder of it's OS-related. Torque uses a lot of sockets, and sets them up and tears them down at a hefty rate. We have the number set to 16K for the scheduler and server processes via ulimit, but we aren't getting much above 1400 between the two processes. Is anyone aware of an issue in 4.4 that might affect this? Thanks, Miles -- Steve Traylen Work Calendar: http://tinyurl.com/22lw9o [EMAIL PROTECTED] CERN, IT-GD-OPS. smime.p7s Description: S/MIME cryptographic signature
Re:
On Jul 13, 2007, at 10:29 AM, vivek chal wrote: hi all! i am not able to uninstall a rpm package in SL3.0.6 .i have used commands rpm -e packagename rpm -evv packagename rpm -e --nodeps packagename rpm -e --noscripts packagename i think i have deleted the package directory by mistake .now what should i do to remove the package completely,so that i can reinstall a fresh copy Are you sure the package is actually there? rpm -qa | grep packagename what errors does rpm -e packagename actually show? Steve -- Vivek Chalotra GRID Project Associate, High Energy Physics Group, Department of Physics Electronics, University of Jammu, Jammu 180006, INDIA. -- Steve Traylen Work Calendar: http://tinyurl.com/22lw9o [EMAIL PROTECTED] CERN, IT-GD-OPS. smime.p7s Description: S/MIME cryptographic signature
Re: Mail from a script
On Jul 12, 2007, at 5:39 PM, Miles O'Neal wrote: Keith Chadwick said... | |Sure! | |=09/bin/mail -s $message_subject $message_mailto $message_file Just in case you don't know, if everything you need is in the script, you can avoid writing a for the message body: And to get the stderror as well add 21 (assuming (ba)sh) /bin/mail -s $message_subject $message_mailto __EOD__ 21 message body here __EOD__ -- Steve Traylen Work Calendar: http://tinyurl.com/22lw9o [EMAIL PROTECTED] CERN, IT-GD-OPS. smime.p7s Description: S/MIME cryptographic signature
Re: SL5 Tomcat5 sun-jdk
On May 8, 2007, at 3:49 PM, Alessio Curri wrote: Hi, I'm testing the new SL5 (i'm using the i386-RC2) and I tried to install tomcat5 (yum install tomcat5). The resulted installation is broken (tomcat won't start out of the box, and there are both sun and gcj jvm). I think the problem is related to the java-sun-compat and the related sun jdk inclusion in the SL5. After a complete reinstall, I tried to install tomcat5, but this time excluding the sun-related packages (yum install -- exclude=java-1.5.0-sun-compat --exclude=jdk tomcat5). It worked fine. Tomcat start and run fine, but of course with java-1.4.2-gcj jvm. The last try involved directly jpacked.org yum repos (after another complete reinstall). After installing the java-1.5.0-sun-compat and the jta-1.0.1-0.b. 4jpp.noarch.rpm, I used yum forcing not to use the sl repo (yum install tomcat5-webapps xml-commons\* --disablerepo=sl-\*). Yum installed the tomcat5 (from jpackage repos). This version used correctly the sun jvm, as I wish. But at the first yum update, the jpackage tomcat5 is replaced with the SL one . How can I install a tomcat5 that use the sun jvm using yum (and\or rpms)? Thanks in advance, Alessio Alessio, You are in luck I've just written up this very topic: https://twiki.cern.ch/twiki/bin/view/EGEE/GLite31JPackage One of the solutions there is to install jpackage's tomcat5 with sun's JDK but you have to take care when you do so. In particular tomcat5 requires xml-commons-jaxp-1.3-apis but this package obsoletes xml-commons-apis which has the result of removing SUN's JDK since this provides xml-commons-apis. In short you must enable the jpackage repositories, install xml- commons-apis followed by SUN's JDK and then java-1.5.0-sun-compat. After this a simple yum install tomcat5 will then work. I would recommend however that you use jpackage's rebuild of JDK rather than SUN's rpm, it avoids all the headaches above. In fact I was considering requesting asking SL to distribute the jpackage rebuilds of JDK rather than SUN's JDK since they are better and avoid this problem. Note I've never tried this on SL5 but it should work as you hit the same problems as I observed on SL4. Steve -- Alessio Curri +39 040 375 8064 Software for Measurement Group Experiments Division Sincrotrone Trieste S.c.p.A. S.S. 14 Km 163.5, in Area Science Park 34012 Basovizza - Trieste (Italy) alessio.curri.vcf -- Steve Traylen [EMAIL PROTECTED] CERN, IT-GD-OPS. smime.p7s Description: S/MIME cryptographic signature
