Re: Security ERRATA Critical: firefox on SL4.x, SL5.x i386/x86_64
Thanks! I had only checked the GUI since lately I've been running in GUI mode primarily on my workstation. palm-to-forehead It didn't occur to me that there's a silently lurking couple of processes, simply because this hadn't happened all the other times FF was upgraded. 0 S 8539 8047 0 81 0 - 15957 wait Apr28 ?00:00:00 /bin/sh /usr/lib64/firefox-3.0.9/run-mozilla.sh /usr/lib64/firefox-3.0.9/firefox 0 S 8556 8539 1 75 0 - 197387 423619 Apr28 ? 00:17:27 /usr/lib64/firefox-3.0.9/firefox Dan W. On Wed, Apr 29, 2009 at 09:46:54AM -0500, Troy Dawson wrote: Hi Dan, Your symptoms sound like you haven't restarted firefox. Try completely restarting firefox. You might have some process lurking in the background if you've already tried restarting firefox. Do a ps ax | grep firefox and kill all it's processes Troy Daniel Widyono wrote: Troy, I don't know if anybody else has experienced this. Upon the upgrade to these packages, my firefox install no longer opens windows. I can't open the preferences window either for instance. A small minimally-sized window appears but its contents are blank. I tried moving aside my personal profile to no avail. What's the easiest method of downgrading packages together from the SL repo? Dan W. On Tue, Apr 28, 2009 at 01:06:00PM -0500, Troy Dawson wrote: Synopsis: Critical: firefox security update Issue date: 2009-04-27 CVE Names: CVE-2009-1313 A flaw was found in the processing of malformed web content. A web page containing malicious content could cause Firefox to crash or, potentially, execute arbitrary code as the user running Firefox. (CVE-2009-1313) After installing the update, Firefox must be restarted for the change to take effect. SL 4.x SRPMS: firefox-3.0.10-1.el4.src.rpm i386: firefox-3.0.10-1.el4.i386.rpm x86_64: firefox-3.0.10-1.el4.i386.rpm firefox-3.0.10-1.el4.x86_64.rpm SL 5.x SRPMS: firefox-3.0.10-1.el5.src.rpm xulrunner-1.9.0.10-1.el5.src.rpm i386: firefox-3.0.10-1.el5.i386.rpm xulrunner-1.9.0.10-1.el5.i386.rpm xulrunner-devel-1.9.0.10-1.el5.i386.rpm xulrunner-devel-unstable-1.9.0.10-1.el5.i386.rpm x86_64: firefox-3.0.10-1.el5.i386.rpm firefox-3.0.10-1.el5.x86_64.rpm xulrunner-1.9.0.10-1.el5.i386.rpm xulrunner-1.9.0.10-1.el5.x86_64.rpm xulrunner-devel-1.9.0.10-1.el5.i386.rpm xulrunner-devel-1.9.0.10-1.el5.x86_64.rpm xulrunner-devel-unstable-1.9.0.10-1.el5.x86_64.rpm -Connie Sieh -Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI LMSS Group __
Re: anaconda crash: Error informing the kernel about modification to partition /dev/sda5
If you don't care about the previous data, just boot into rescue mode, and use fdisk to write a clean empty partition table to the disk, then reboot into installation mode. That's cleared up some issues for me in the past. Dan W. Error informing the kernel about modifications to partition/dev/sda5--Device or resource busy. This means Linux won't know about any changes you made to /dev/sda5 until you reboot--so you shouldn't mount it or use it in any way before rebooting.
Re: Second class users?
I liked the simplicity and robustness of Ken's answer: use unix groups. We would like to create accounts for restricted users To be sure we understand the requirements, what precisely do you mean by restricted users? Do you *only* mean the following? These users would have access to the filesystem as appropriate, but would not be allowed to run the applications living under /opt and /usr/local. If you only mean the above, then in the context of primarily for data sharing purposes, what precisely do you mean by access to the filesystem as appropriate? Regards, Dan W.
Re: EL4.4 and older Logitech PS2 mouse
Miles, What's your X mouse driver? I had this issue at one point as well, and it turned out to be a change in IMPS/2 or PS/2. I switched to the other and it worked fine from then on. Dan W.
Re: Sendmail To and CC are not filled error
Please make sure it works by sending an email from gmail (which allows an empty To: field and many Bcc: - yahoo and hotmail don't allow it) and send to multiple recipients in the Bcc with one of those recipients as your mail server with the stock sendmail.mc and sendmail.cf, this would then be an identical test to what I'm doing. I just tried (again) from mutt, which allows empty To: and Cc: lines. This time I Bcc:'ed you as well. Let me know if you get it (subject: test2). I got this and my previous test just fine on my stock sendmail server (well, stock minus allow unresolved hostnames which I always comment out). Dan W.
Re: Sendmail To and CC are not filled error
Do you have the standard SL sendmail.mc and sendmail.cf files? If not, try them first. I do, and It Works For Me. On SL 4.x at least. Dan W. On Fri, Sep 28, 2007 at 03:05:24PM +1000, Michael Mansour wrote: Hi, Sorry if this is way off topic, but I've spent the past few hours web searching and trying different things for the following sendmail error: 554 5.7.1 To: and CC: are not filled which results when an email comes into the system where the sender has only populated the Bcc field and not the To or CC fields. I don't want these messages rejected yet can't seem to find anyway within sendmail to stop the rejection and allow the messages through. Any ideas what I should try to get this working? Thanks. Michael.
Re: Changing BIOS settings on nodes
I would think that if you are copying all of the BIOS settings, then the checksum should be right. Why? As I see it, the checksum is presumably created and stored somewhere when you select save in the BIOS setting program. Since this has been bypassed by using /dev/nvram the stored checksum will not match the new BIOS settings. It might have worked if the checksum value was stored in the BIOS settings and the checksum test was only for the rest of the settings but this would appear not to be the case. It sounds like the question is: if you copy from another known good BIOS, perhaps the (known good) checksum is being copied as well (in-band as opposed to out-of-band), and therefore the second BIOS should come up fine. However, perhaps the assumption that the checksum is in-band is not correct? Maybe there's a second NVRAM just for the checksum? Maybe the checksum is not accessible to the kernel in order to be exposed via /dev/nvram? Maybe the checksum includes a parameter from the hardware itself, e.g. MAC address or motherboard serial number or what have you, which precludes transfering a known good BIOS image from one machine to another without going through the manufacturer's checksum routine each time? *sigh* Good luck, Dan W.
Re: rsync error on large directories?
Volume of data isn't the only measure of large - the number of files is important too. I started having problems at about 45K - 50K files per directory, using ext3 (pre-hashed-b-trees). I forget total # files in top level. This particular issue wasn't rsync-specific, however. It also used an enormous amount of RAM: talks to the other while this is happening. I think this was taking an hour or so, but this _was_ a few years ago. Same experience, and these _were_ rsync-specific issues. See below for my solution. The rsync gurus opined that it was better to backup this way than to backup a single file, but my experience suggests otherwise; I now create a filtered filesystem image and use rsync to update that. It depends on your usage. If you only update one or two files between backups, rsync is better way to go (but see below for how to do it better). So, basically, instead of rsync'ing the entire top level which forces rsync to build an entire mapping of all the sub-directories, just go into each sub-directory and rsync individually. This works better the more balanced your trees are, of course. This works for e.g. home directories which are hashed (/home/a-g/, /home/h-m/, /home/n-t/, /home/u-z/ for example). The script I use has a subroutine which does an rsync on a specified directory path. The main routine just loops through all subdirectories in the top-level, and calls the subroutine for each entry. This breaks the problem down into manageable chunks. You can modify this to go two levels down, etc. or recursively call itself down to a user-specified depth. I got lazy and it Worked Enough For Me. :) HTH, Dan W.
Re: dag sl4.4 perl-Win32-ODBC et al. missing?
Thanks for the response. Since 1.58-1 was installed in the repository early 8/4, and 1.58-2 replaced it rather quickly in afternoon 8/5, I think it was actually just an incorrect build (incorrect meaning it doesn't work with vanilla sl44 and dag; I have no idea if perl-Win32* exist in some other distro). It's also telling that the dag directory still does not contain perl-Win32*, and perl-DBI-1.58-2 does not require perl-Win32-ODBC. That said, it's good to be aware that your update schedule may occasionally collide with his. With regards, Dan W. Hi Dan, I'm glad it ended up installing correctly. Just for your information. We mirror the dag directory just once a day, so it's possible that we updated when he was in the middle of updating something and we didn't get everything.
dag sl4.4 perl-Win32-ODBC et al. missing?
Greetings, It appears that a new perl-DBI package was installed in dag's redhat/el44 tree: perl-DBI-1.58-1.el4.rf.i386.rpm This package apparently requires perl(RPC::PlClient) = 0.2000 perl(RPC::PlServer) = 0.2001 perl(Win32::ODBC) none of which could be found at 9:45AM EST. Is this simply a delay of new packages making it downstream, or am I supposed to find them in another repository? I noticed this via the automated nightly yum update. As of now, my system is quite happy with perl-DBI-1.40-8 from the original disribution, but I am fond of the dag repository and would like to keep it enabled. The new perl-DBI package seems to only have appeared this morning: -rw-r--r-- 1 1007 1007 840735 Aug 04 01:06 perl-DBI-1.58-1.el4.rf.i386.rpm Thanks, Dan W.
Re: Upgrade from SL 4.4 to SL 5
I just upgraded in order to install the latest gnucash (2.2.0). I generally had to manually remove several el4 packages (using --nodeps) and manually re-install the el5 packages (I think these were primarily packages from the dag repos) before everything was quite happy. One package had RHEL4 in the name instead. I believe most of the manual stuff centered around multimedia (e.g. mplayer, xine, xmms and assorted plugins). One other issue I ran into when upgrading from sl44 to sl5 is the currently open problem of SATA ports with nothing attached. Fedora Forums has some info about working around the resulting hang when the module is loaded (essentially using options ata_pii noprobe or something very similar to that to prevent loading the SATA module). Apparently the upstream vendor will eventually be incorporating a kernel patch which fixes this. Regards, Dan W. On Fri, Jul 27, 2007 at 09:47:05AM -0400, Harold Norris wrote: Hi, I have enjoyed working with SL 4.4, but some of the programs I wanted to run needed upgraded programs and files. After compiling numerous libraries and programs, I finally came to the realization that it would be a lot easier to upgrade to SL 5. The upgrade from your DVD.iso went well, but when I went to use the updater, I got the following errors: kernel conflicts with e2fsprogs 1.37-4 Missing Dependency: freetype = 2.1.9-6.el4 is needed by package freetype-utils Missing Dependency: freetype = 2.1.9-4.el4 is needed by package freetype-utils The new kernel is: kernel-headers - 2.6.18-8.1.8.el5.x86_64 updates kernel-headers - 2.6.18-8.1.3.el5.x86_64 kernel - 2.6.18-8.1.8.el5.x86_64 updates kernel - 2.6.18-8.1.3.el5.x86_64 kernel-devel - 2.6.18-8.1.8.el5.x86_64 updates kernel-devel - 2.6.18-8.1.3.el5.x86_64 kernel-doc - 2.6.18-8.1.6.el5.noarch updates kernel-doc - 2.6.18-8.1.3.el5.noarch And the new freetype is: freetype - 2.2.1-19.el5.x86_64 updates freetype - 2.2.1-17.el5.x86_64 freetype-devel - 2.2.1-19.el5.x86_64 updates freetype-devel - 2.2.1-17.el5.x86_64 freetype-demos - 2.2.1-19.el5.x86_64 updates freetype-demos - 2.2.1-17.el5.x86_64 freetype - 2.2.1-19.el5.i386 updates freetype - 2.2.1-17.el5.i386 Did I overlook something ? Thanks Harold Norris
Re: Install Resolution
Ibid. Similar experiences with SL4 and SL3 and random dumb generic RAID array. Dan W. Jon, I absolutely back up what you say. Presenting logical volumes less than 2Tbytes then using LVM to join them back up into larger LVs is the way to go.
Re: External (USB) DVD burner that works with SL?
FWIW over a year ago I purchased a Memorex DVD dual+-format double layer external usb/firewire recorder, has been working with SL4 and SL5, playing movies and recording backups onto data DVD's. DVD+r/-r: 16x write DVD+R9 (dual-layer) 4x write DVD+RW/-RW 4x rewrite DVD-ROM 16x read CD-R 48x write CD-RW 24x rewrite CD-ROM 48x read hi-speed usb 2.0, firewire Part #3202 3288 Dan W. On Fri, Jul 27, 2007 at 05:39:36PM -0700, Michael Hannon wrote: Hi, folks. We're in the market for an external DVD writer with a USB interface that works with Scientific Linux. This could be SL 3, 4, or 5. The format doesn't much matter either, i.e., +R, -R, +RW, -RW. Some of the guys here just want to dump some data. If you have any recommendations (positive or negative) about such devices, please let me know. Thanks. - Mike -- Michael Hannonmailto:[EMAIL PROTECTED] Dept. of Physics 530.752.4966 University of California 530.752.4717 FAX Davis, CA 95616-8677
