[CentOS] Controlling the order of /dev/sdX devices?
Hi CentOS 5.4(final) 2.6.18-164el5PAE. I am trying to prevent removable USB and eSATA devices from occupying /dev/sdX devices ahead of a 3ware RAID controller. For example: at boot, if a USB drive and eSATA HDD (connected to an LSI 1068E onboard controller, reflashed in "IT" mode to handle hotplug devices) were both present, they would occupy devices /dev/sdb and /dev/sdc, ahead of the RAID controller which ends up as /dev/sdd. As these are removable devices, they should normally get handled by custom udev script looking for adds matching KERNEL=="sd[c-z][0-9]" ,SUBSYSTEM=="block", so the volume handled by RAID controller gets grabbed by udev but fails to mount and subsequent udev plug events fails due the slots left empty below /dev/sdd. If no hotplug devices are present while booting, fstab handles mounting of the system and RAID volume: SATA system HDD /dev/VolGroup00/LogVol00 / RAID array LABEL=STORE /store ## mounts == /dev/sdb1 I realise this description is kind of a tangle, but i am essentially looking for a way to hard-map the 3ware RAID controller to /dev/sdb (UUID won't work as there are multiples of this system) before PCI (?) enumeration picks up the USB and LSI-managed devices so that udev can take care of the device at /dev/sdc and above. I've tried blacklisting the mpt and usb-storage modules and short-circuiting SUBSYSTEM=="block" devices in 05-udev-early.rules, all with zero or negative effect. rc.sysinit doesn't appear to be the right place and that's about as deep down as i know how to go. cheers, cs ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Digest, Vol 74, Issue 31
thanks for the reply, Phil It would, were udev not inserting USB and/or eSATA drives at /dev/sdb1 and/or /dev/sdc1 and exposing the array to the udev rule intended to handle only removable devices (at sdc or sdd). The array then mounts unpredictably in /media/xxx-sdc1 or sdd1 - not what is wanted - depend on how many removable devices are plugged at the time of rebooting. Of course, a single removable device will camp at sdb, which is out of reach of udev so the whole hotplug thing is broken until someone removes all of the devices at site, allowing a clean boot. mapper correctly places the / filesystem higher in position in rc.sysinit, followed by start_udev (where the damage gets done) and finally fstab evaluation way down the line. I suppose i could just hardwire the array mount into rc.sysint to engage after modules get loaded and hopefully before start_udev, unless there is a better way to enforce it. I'm not sure at this stage (need to analyse that ~1000-line script) if there is a suitable insertion point. It would be really good if it could be done outside of rc.sysint in some predictable place. We're "stuck" (but not unhappily) with this kernel/rev for the foreseeable future - i have over 100 of these systems and they are housed behind VPN'd networks, which mitigates somewhat their inevitable vulnerabilities. regards, - csawyer 30. Re: Controlling the order of /dev/sdX devices? (Phil Schaffner) CentOS 5.4(final) 2.6.18-164el5PAE. I am trying to prevent removable USB and eSATA devices from occupying /dev/sdX devices ahead of a 3ware RAID controller. For example: at boot, if a USB drive and eSATA HDD (connected to an LSI 1068E onboard controller, reflashed in "IT" mode to handle hotplug devices) were both present, they would occupy devices /dev/sdb and /dev/sdc, ahead of the RAID controller which ends up as /dev/sdd. As these are removable devices, they should normally get handled by custom udev script looking for adds matching KERNEL=="sd[c-z][0-9]" ,SUBSYSTEM=="block", so the volume handled by RAID controller gets grabbed by udev but fails to mount and subsequent udev plug events fails due the slots left empty below /dev/sdd. If no hotplug devices are present while booting, fstab handles mounting of the system and RAID volume: SATA system HDD /dev/VolGroup00/LogVol00 / RAID array LABEL=STORE /store ## mounts == /dev/sdb1 I realise this description is kind of a tangle, but i am essentially looking for a way to hard-map the 3ware RAID controller to /dev/sdb (UUID won't work as there are multiples of this system) before PCI (?) enumeration picks up the USB and LSI-managed devices so that udev can take care of the device at /dev/sdc and above. I've tried blacklisting the mpt and usb-storage modules and short-circuiting SUBSYSTEM=="block" devices in 05-udev-early.rules, all with zero or negative effect. rc.sysinit doesn't appear to be the right place and that's about as deep down as i know how to go. cheers, cs -- Message: 30 Date: Thu, 31 Mar 2011 10:24:42 -0400 From: Phil Schaffner Subject: Re: [CentOS] Controlling the order of /dev/sdX devices? To: Message-ID: <4d948eaa.2070...@nasa.gov> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Cal Sawyer wrote on 03/31/2011 08:13 AM: > Hi > > CentOS 5.4(final) 2.6.18-164el5PAE. I hope you are aware that you are using a very obsolete OS with a lot of known (i.e. exploitable) security holes and bugs that have subsequently been fixed. ... > I realise this description is kind of a tangle Indeed. Why does a line in /etc/fstab like LABEL=STORE /store ext3defaults1 2 not work? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Controlling the order of /dev/sdX devices?
Apologies in advance for excerpting or leaving out the messages sent to the list as i was in digest mode so got them all in one lump. Rudi Ahlers: You could assign a LABEL to each hard drive. The LABEL is attached to the drive's UID (I think?) so even if you move the drive to anther port it will still be accessible via the same LABEL > Unfortunately, the removable devices are utterly random and rarely if ever > the same device seen twice. > Kind Security Advisors, i appreciate the potential issues resulting from not > upgrading. These systems are behind VPNs, so out of reach other than from > within a secured environment. They are not production systems per se - i > consider them more as appliances and that necessitates a certain > hands-off-it-works approach. If gives any relief, front-facing production > systems i manage _are_ patched up to the earholes. However, i will take your > advice seriously and look into the logistics of performing remote > security-level patches without breaking something irreparably. > Lamar, thank you for your comments. My suspicion is that bus enumeration is > the source of the initial device ordering - a similar thing happens when > installing a secondary NIC, which sets itself up as eth0/eth1 ahead of the > onboard NIC ports if they haven't; been preconfigured. I'm sure you've all > read about that issue. However, I'm not aware of any way to alter the order > of enumeration. Module load order appears to occur further down the chain - > or does it? I have this synopsis of rc.sysint: http://www.comptechdoc.org/os/linux/startupman/linux_surcsysinit.html and will see if it's possible to get my array statically mounted before all of the dynamic stuff licks in. thanks, all! If anyone has any ideas that aren't security related ;) please feel free. - cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Controlling the order of /dev/sdX devices?
The reason for the udev hotplug rule is simply for the purpose of mounting removable devices as read-only. If udev is left to its devices, everything plugged up is read-write which is verboten in this application. Unfortunately, there seems to be no way (i've found) to distinguish, at device/bus level, between a system HDD, a hardware RAID volume and an eSATA device and handle the eSATA device uniquely from others. All eSATA and USB devices _must_ mount read-only. If everything is lined up at boot, sda and sdb are camped via fstab and udev deals with sdc and above, mounting what are known to be removable devices as r/o. Shotgun, i know, but there is no way of knowing in advance what devices the system (er, appliance) will see. tangled, huh? thanks - csawyer Robert Heller heller at deepsoft.com Thu Mar 31 14:20:55 EDT 2011 Previous message: [CentOS] CentOS Digest, Vol 74, Issue 31 Next message: [CentOS] figuring out LogVol details for mount Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] At Thu, 31 Mar 2011 18:23:00 +0100 CentOS mailing list wrote: > > thanks for the reply, Phil > > It would, were udev not inserting USB and/or eSATA drives at /dev/sdb1 > and/or /dev/sdc1 and exposing the array to the udev rule intended to > handle only removable devices (at sdc or sdd). The array then mounts > unpredictably in /media/xxx-sdc1 or sdd1 - not what is wanted - depend > on how many removable devices are plugged at the time of rebooting. Of > course, a single removable device will camp at sdb, which is out of > reach of udev so the whole hotplug thing is broken until someone removes > all of the devices at site, allowing a clean boot. Do you have some *nonstandard* udev rule for hot plug devices? The *standard* hotplug udev rules are not tied to specific ranges of sdXX's -- my IDE-based laptop will properly handle a hot plugged USB device at /dev/sda for example. The hot plug logic should also not mess with not hot pluged devices. If your RAID array is mounted in /etc/fstab (or has a 'noauto' line in /etc/fstab with the idea of mounting it manually later or has something in automount's config for automounting it), the hot plug system should not touch it, no matter what /dev/sdXX it happens to land at, so long as you are using volume labels or some such to reference the mountable volumes. - cal sawyer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Controlling the order of /dev/sdX devices?
Nope sir. Assume never the same device twice and no control over those devices, so UUID is out of the question. thank you, - csawyer From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Rudi Ahlers Sent: 01 April 2011 09:24 To: CentOS mailing list Cc: Cal Sawyer Subject: Re: [CentOS] Controlling the order of /dev/sdX devices? On Fri, Apr 1, 2011 at 9:54 AM, Cal Sawyer wrote: Apologies in advance for excerpting or leaving out the messages sent to the list as i was in digest mode so got them all in one lump. Rudi Ahlers: You could assign a LABEL to each hard drive. The LABEL is attached to the drive's UID (I think?) so even if you move the drive to anther port it will still be accessible via the same LABEL > Unfortunately, the removable devices are utterly random and rarely if ever the same device seen twice. Yes, that's why you assign a LABEL to the device :) If the same hard drive gets used on the same server, but on random ports every time then the LABEL will still stay the same. I have a similar setup where I mount about 40-odd USB drives to a server on a regular basis. They each have their own mount points in /mnt/usb-hdd/xx and irrespective of which drive I connect to which USB port, or on which order, they all get mounted where they're supposed to :) -- Kind Regards Rudi Ahlers SoftDux Website: http://www.SoftDux.com Technical Blog: http://Blog.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Controlling the order of /dev/sdX devices?
Nope, no LVM on the RIAD array. It just needs to load right after the main LVM so that something removable doesn't wiggle its way in and mess up the device order. Yes, the suggestion from Robert H looks promising - working on it now. Did i say i hate udev? I thought there was going to be a replacement for it at some point? - cal sawyer -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Lamar Owen Sent: 01 April 2011 14:18 To: CentOS mailing list Subject: Re: [CentOS] Controlling the order of /dev/sdX devices? On Friday, April 01, 2011 04:23:40 am Rudi Ahlers wrote: > Yes, that's why you assign a LABEL to the device :) According to the OP's initial message, I think he's already doing this: >> SATA system HDD /dev/VolGroup00/LogVol00 / >> RAID array LABEL=STORE /store ## mounts == >> /dev/sdb1 But I could be wrong. The issue seemed to be that the udev rule prevented the detection of the LVM on that RAID completely when it came up as /dev/sdd. The other udev rule in-thread seems to be a possible solution; will be interesting to see if it works. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Controlling the order of /dev/sdX devices?
I think that everyone lese lives in a far more ordered universe than i do. My "problem" - no, wait - "challenge" is that i have zero control over the origin of incoming media on USB and eSATA. Could be any brand of USB stick sold under the sun or HDDs formatted FAT32, NTFS, ext2/3. The only constants are things i directly control (sysdisk, RAID) - everything else is a crap-shoot. Everyone else can use labels. I don't know about you but it "feels" like mounting a RAID array, possibly with an active mySQL database on it under udev is kind of disaster-prone. I would much rather mount via fstab. - csawyer -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Brunner, Brian T. Sent: 01 April 2011 14:51 To: CentOS mailing list Subject: Re: [CentOS] Controlling the order of /dev/sdX devices? centos-boun...@centos.org wrote: > Nope sir. Assume never the same device twice and no control > over those devices, so UUID is out of the question. UUID is out of the question where I have 3 drives (main and two backup) with "wear leveling" wherein ANY of the drives, put in /dev/sda's position, is the boot drive, the identical backup on /dev/sdb will get backed-up-to on a daily basis, and on a weekly basis the drive in /dev/sdb moves to /dev/sda's connector (becoming the boot drive), '/dev/sda' goes off-site, and the third moves to /dev/sdb's position (and gets backed-up-onto promptly. LABEL also fails here. > Yes, that's why you assign a LABEL to the device :) If the > same hard drive gets used on the same server, but on random > ports every time then the LABEL will still stay the same. I > have a similar setup where I mount about 40-odd USB drives to > a server on a regular basis. They each have their own mount > points in /mnt/usb-hdd/xx and irrespective of which > drive I connect to which USB port, or on which order, they > all get mounted where they're supposed to :) This is excellent where each drive has distinct content. Insert spiffy .sig here: Life is complex: it has both real and imaginary parts. //me *** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated** ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Controlling the order of /dev/sdX devices?
ack, i can feel my hair greying ... again. *But*, i do appreciate your insight into the future direction of CentOS device handling. Having read this, i'm going to bite the bullet and dive into smarting-up my udev rules, feeding a handler script that will decide what to do about what kind of device before blindly executing mounts based on KERNEL values. Two silly questions: 1. in udev rule's RUN+-"", can i pass an arbitrary string that's not one of the %tokens? I pass %k %n, of course, but i'd like to tag something to indicate which rule was processed in a downstream script. 2. Will udev, as it develops (i hope), will there be any provision blacklisting/whitelisting devices? Were it not for the removable-read-only requirement, i'd have been content with HAL doing the work. It does work well for handling CD/DVDROM discs (the 3rd type of removable we deal with) but doesn't do granular device detection well enough to set read-only for removable media only and a read-only RAID array is not that useful. many thanks - good weekend, all - csawyer -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Lamar Owen Sent: 01 April 2011 15:19 To: CentOS mailing list Subject: Re: [CentOS] Controlling the order of /dev/sdX devices? On Friday, April 01, 2011 09:53:06 am Cal Sawyer wrote: > Nope, no LVM on the RIAD array. It just needs to load right after the main > LVM so that something removable doesn't wiggle its way in and mess up the > device order. Ok, so the LVM line was for the previous filesystem; it wasn't completely clear from the post. The LABEL line was clear, though. > Yes, the suggestion from Robert H looks promising - working on it now. Did i > say i hate udev? I thought there was going to be a replacement for it at > some point? udev *is* the replacement, and with C6 you're going to find it far earlier in the boot process, inside the initramfs courtesy of dracut. Like it or not, fixed always-the-same device ids are going away for disk drives in Fedora-derived (and by extension, Red Hat derived) distributions. udev might seem to be overkill, but it is what it is and it's here to stay, in CentOS-land at least, for as long as C6 is supported. Might as well bite the bullet and learn how to do what needs to be done in udev. Once figured out, you might find it more powerful than fixed ids ever were; I don't know, because I've not tried to do things like your situation. Let us know if the suggeston works, and how well or not well it works. Your 'read-only for all external drives' situation is unique; note that there are times that I've booted up a box with a removable plugged in, and the removable failed to enumerate at all. It would only enumerate when it was hotplugged after the kernel systems were up; the particular case is with a USB3 drive and an ExpressCard USB 3 controller on Fedora 14, but I have had the issue with USB 2 devices on previous Fedoras, that might be reflected in C6. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is Centos 5.5 too old fro Google Chrome?
Hi I use the Chromium build from: http://www.cs.bham.ac.uk/~cxs548/chrome The highest Chromium rev you can run with the RHEL5.x flash-plugin chrome-10.0.612.0.tar.gz is v10. chrome-11 is incompatible with flash-plugin-10.2.152.27-0.1.el5.rf. Looks like flash-plugin_10.2.153.1-0.1.el5.rf is available now, so v11 might be OK. It seems like the Chromium build leads flash-plugin by one version, but i haven't been actively upgrading as each becomes available. - csawyer -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Akemi Yagi Sent: 04 April 2011 10:00 To: CentOS mailing list Subject: Re: [CentOS] Is Centos 5.5 too old fro Google Chrome? On Sun, Apr 3, 2011 at 10:05 PM, Vnpenguin wrote: > On Mon, Apr 4, 2011 at 06:51, Todd Cary wrote: >> I tried to install Google Chrome and received the dependencies >> error. Is Centos too old for the new Chrome or is there an older >> Chrome version that is compatible? > > You need CentOS 6 or Fedora 14 to run Google Chrome :-) Some people reported successful installation of Chrome on CentOS-5 in this forum thread (see note #15): https://www.centos.org/modules/newbb/viewtopic.php?topic_id=23746 Akemi ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Tips for motherboard with multiple PCI / PCI-e slots
Re quad-port NICs: AOC-SG-i4 is good, too, and smaller than the UG version. iirc, it uses a newer Intel chipset as well. Oddly, it isn't listed on Supermicro's site except as a PDF factsheet. I have a few of them and they work well. There's also the Intel EXPI9404PTL, but here in the UK it's a fair chunk more expensive than the SM card. cheers, - csawyer -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Brunner, Brian T. Sent: 04 April 2011 14:12 To: CentOS mailing list Subject: Re: [CentOS] Tips for motherboard with multiple PCI / PCI-e slots centos-boun...@centos.org wrote: > Hi, > > I need to fit at least three NICs and I was looking for > motherboard models that contain 3 or 4 CPI (or PCI-e) slots and works > with CentOS. You can get 4 etherports on one card... For 17 examples: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100010064%20 600013873&IsNodeId=1&bop=And&Order=RATING&PageSize=20 How many of those work well with Linux (of whatever variety) I don't know. One board claiming RedHat compatibility with a loadable kernel module is http://www.supermicro.com/products/accessories/addon/AOC-UG-I4.cfm Another article that might give fast, cheap, albeit old answers is http://www.freelabs.com/~whitis/hardware/quartet.html Why do you need 3 network interface cards? Would two NICs with 2 etherports each, or 1 4-port card meet your need? > I had a problem in the past with some models that had a bug > and did not work well with linux (ok with windows) so that's > way I am asking this here. Are you building a desktop/personal machine, or a server? Are you picky about power/heat/noise factors of the Mobo? Sorry about your 5 options being narrowed down to 30, but the question asked was really imprecise. Insert spiffy .sig here: Life is complex: it has both real and imaginary parts. //me *** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated** ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can anyone suggest a SCSI 3 card in either PCI-X or PCI-E x 4 for a Dell Poweredge 2900?
I like my Atto ExpressPCI UL5D. Supports LUNs > 2TB, which iirc, Adaptec still (?) doesn't. - csawyer -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Benjamin Hackl Sent: 08 April 2011 10:31 To: centos@centos.org Subject: Re: [CentOS] Can anyone suggest a SCSI 3 card in either PCI-X or PCI-E x 4 for a Dell Poweredge 2900? On Thu, 07 Apr 2011 12:46:01 -0700 John R Pierce wrote: > On 04/07/11 10:51 AM, Lamar Owen wrote: > > Dell typically shipped Adaptec cards; I seem to remember 39160's > > being shipped in some 1850's I have. That would be more than > > enough performance for what you want, and they aren't expensive on > > eBay. Can confirm that. We have a PowerEdge 2900 here with an Adaptec ASC-39320A connected to a tape drive running for almost 4 years without any problems. Brgds ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] INN removed from CentOS 6
In a past life when i was working with IRIX systems, i changed from innd to DNews (http://netwinsite.com/dnews/install.htm, http://netwinsite.com/dnews/faq1.htm#2). Looks like it's been out of development since 2007 (but what's changed nntp-wise since 2007? dunno), but it was a piece of cake to configure and administer. - csawyer -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Reynolds McClatchey Sent: 27 April 2011 14:57 To: centos@centos.org Subject: [CentOS] INN removed from CentOS 6 I use inn to make internal company announcements and discussions available to remote offices. I note inn is removed form RHEL 6. What replaces inn? http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/apc.html Will inn be available from elsewhere? Will I have to compile it? Should I modify my scripts to create and install html files for a web server? That would make article deletion, archiving, and maintenance more difficult than it is with the inn nntp server. Is there some "forum" type package that would be better than the inn system? -- M Reynolds McClatchey JrVP Engineering and Inventory Southern Aluminum Finishing Co Inc 404-355-1560 x222 Voice 1581 Huber St NW404-350-0581 Fax Atlanta GA 30318 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Is ATRPMs dead?
Haven't been able to reach atrpms.net for over a week from London, UK, when i last looked for it after a couple of intervening months. Did i miss something? And if atrpms is truly defunct, where's a good place to obtain updated versions of vlc and mplayer now? thanks! - cal ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is ATRPMs dead?
Thanks to Earl for the NUX repo recommendation. Good VLC and ffmpeg versions (for CentOS) here. From what i can tell, atrpms died a death earlier this year or the end of last cheers - cal sawyer Earl A Ramirez wrote: To: CentOS mailing list Subject: Re: [CentOS] Is ATRPMs dead? On 14 Sep 2015 14:12, "Cal Sawyer" wrote: Haven't been able to reach atrpms.net for over a week from London, UK, when i last looked for it after a couple of intervening months. Did i miss something? And if atrpms is truly defunct, where's a good place to obtain updated versions of vlc and mplayer now? thanks! - cal ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Have never used ATRPMS but a good alternative for at least VLC is Nux repo; I have been using it since EL 6 and it works just as good on EL 7. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] journaled quotas in CentOS6?
Hi CentOS 6.7 (kernel 2.6.32-573.el6.x86) ... Wanted to set up group quotas on a new ext4 filesystem. When i was initialising via quotacheck, received this message > quotacheck -vcg /HOMES quotacheck: Your kernel probably supports journaled quota but you are not using it. I liked sound of that, so i brushed up on the procedure and modified the mount line in fstab to: defaults,noatime,grpjquota=aquota.group,jqfmt=vfsv0 on doing a mount /HOMES -o remount, i was met with this: mount: /HOMES not mounted already, or bad option and was unable to mount the filesystem until i removed the journaling options I've come across how-tos and blogs by people who were doing this in CentOS6.5. The mount manpage makes no mention of jquotas Any thoughts on how to get jquotas in 6.7? thanks - cal ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Best way to duplicate a live Centos 5 server?
From: Les Mikesell Subject: Re: [CentOS] Best way to duplicate a live Centos 5 server? To: CentOS mailing list On Fri, Jun 8, 2012 at 12:04 PM, Scott Silva wrote: >> Am I missing something glaringly obvious here, or is the only way I'm >> going be able to migrate is to shutdown the C5 server for a few hours >> while duping the old drives? Would greatly appreciate any pointers how >> best to do this. > You could always rsync the old server to the new one... a few runs will > get > 99% of the files, and a quick run after the shutdown can get the rest... > Have > a tar file ready of the needed config changes ready and untar it and > start up > the new system... An interesting variation on this is to use 'ReaR' to back up and restore the machine, essentially cloning it but give the copy a different IP address as you bring it up. Then when the clone is close to ready to take over, shut down your apps for the time it takes a final rsync to fix up the differences (in the data areas only - avoid /etc/, (etc.), then switch the IP. ReaR is in active development now and is very usable. It is a set of shell scripts designed to run live backups that are capable of restoring to bare metal. It makes a new boot iso with tools from the running system to reconstruct the filesystem (including lvm/raid, etc.) and restore on top of that. Several backup methods are supported but tar to an nfs location is probably the easiest to set up. With a small amount of extra work you can tweak the filesystem layout, etc. if you don't want an exact clone. With hardware differences you might need to tweak modules and build a new initrd, too. ReaR is packaged in EPEL as rear. ReaR has suddenly become very interesting to me, probably explaining why it utterly fails to work properly (for me).I'm using 1.13 to pull a USB-based recovery image, but there's an error in the backup/NETFS/default/50_make_backup.sh script that doesn't mount the USB device after the mkrecovery step, so subsequent tar fails on write to the non-existent mountpoint. I fixed that, but on recovery it fails to mount the necessary directories on the restore drive as well, so "rear recover" quickly bombs out. Is anyone having any success actually using ReaR on CentOS 6.x? - csawyer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Best way to duplicate a live Centos 5 server?
Subject: Re: [CentOS] Best way to duplicate a live Centos 5 server? To: CentOS mailing list On Mon, Jun 18, 2012 at 11:21 AM, Cal Sawyer wrote: >> > >> > ReaR has suddenly become very interesting to me, probably explaining why >> > it utterly fails to work properly (for me).I'm using 1.13 to pull a >> > USB-based recovery image, but there's an error in the >> > backup/NETFS/default/50_make_backup.sh script that doesn't mount the USB >> > device after the mkrecovery step, so subsequent tar fails on write to >> > the non-existent mountpoint. I fixed that, but on recovery it fails to >> > mount the necessary directories on the restore drive as well, so "rear >> > recover" quickly bombs out. Is anyone having any success actually using >> > ReaR on CentOS 6.x? - csawyer > It intentionally doesn't deal with drives the kernel has marked as > removable. I had trouble with that with the main drives on a SAS > hotswap backplane in an earlier version but I think that is fixed now. > > I'd recommend asking how to override this on the ReaR mail list. > While the code seems usable (and yes, I have succeeded in using it on > Centos 6x.), the documentation either doesn't exist yet or is very out > of date. But, the authors are very responsive and it would be good > to let them know about any bugs or usability problems. The mail list > is still at sourceforge although the code has been moved to github and > there is talk of moving the list elsewhere. > > -- Les Mikesell lesmikes...@gmail.com ReaR hasn't posed any insurmountable problems with USB removable media but i can see SATA/SAS needing some massaging in the device detection dep't. Yes, i've gotten myself on the ReaR mailing list now. You're right - documentation is pretty dire. Guess i'm not alone in hating doing it. USB backup is broken due to the order in which path variables get set - sure is lot of fun trawling through the scripts to find out what gets set when. Hope the ReaR maintainers are interested in this and haven't gotten themselves mired in tape archive integration - i would have thought USB backup was the winner in terms of getting broad acceptance as a bare-metal DR solution. However, when it works - wow. Just restored an HP dl360 w/HWRAID to a Presario desktop machine and it lives! No network, but that's small beans compared to the larger win. - csawyer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS6.2: installation at specific kernel level
Hi, all I have a number of machines that are out of sync with one another by virtue of having done a yum update after a base 6.2 install at different times (all were previous CentOS 5.3) Consequently, systems are a mix of 2.6.32-220.7.1, 2.6.32-220.13.1 or 2.6.32-220.17.1. So 2 questions: - Is it possible to perform a yum update (or another other kind of update), specifying installation of, say, kernel 2.6.32-220.17.1 along with the packages that were relevant at the time when 2.6.32-220.17.1 was current? - Is it possible to capture and save for future installations the current kernel rev and associated packages as exist in the repos today and install as a "frozen-in-time" distribution? thanks! - c sawyer ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Configure LAGG Interface?
In my experience, LAG/LACP won't provide aggregatation, only failover and fault tolerance. For link aggregation, you don't need to configure the switch ports - just set bonding to mode=6 for balanced transmit/receive and plug up the the NICs to a group of ports on the switch. However, balance-alb doesn't help with single stream rsync/FTP sessions, etc, but helps a lot with concurrent transmits/receives as encountered in typical fileserver scenarios. - c On 06/08/12 17:00, centos-requ...@centos.org wrote: > Message: 30 > Date: Mon, 06 Aug 2012 13:56:41 +0100 > From: Giles Coochey > Subject: Re: [CentOS] Configure LAGG Interface? > To: centos@centos.org > Message-ID: <501fbf09.5080...@coochey.net> > Content-Type: text/plain; charset="iso-8859-1" > > On 02/08/2012 02:00, Tim Nelson wrote: >> > - Original Message - >>> >> On 01.08.2012 21:17, Tim Nelson wrote: >>> Greetings- I'd like to configure multiple copper NICs on a server >>> running CentOS 6.2 in a LAGG configuration for better throughput to >>> the core switch. After quite a bit of searching, I'm not seeing >>> anything of the sort. Is LAGG specific to the BSD world and the HP >>> switches I'm running? Or, does it go by a different name? Bonding >>> perhaps? If so, is bonding compatible with LAGG? >>> >>> --Tim >>> ___ >>> CentOS mailing list >>> CentOS@centos.org >>> http://lists.centos.org/mailman/listinfo/centos >>> >> Hi Tim, >>> >> >>> >> In Centos you would be doing "nic bonding", it's the same thing. >>> >> >> > The big question though, can I bond two NICs on a CentOS system, and >> > connect those interfaces to two LAGG ports on my switches? >> > >> > > http://centoshelp.org/networking/nic-bonding/ > > Configure the switches as a LACP port-channel, you probably want to use > a host mode (e.g. silent) configuration. > > -- Regards, Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 > 877438 http://www.coochey.net http://www.netsecspec.co.uk > gi...@coochey.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Digest, Vol 91, Issue 7
On 07/08/12 17:00, centos-requ...@centos.org wrote: > Message: 6 > Date: Mon, 06 Aug 2012 21:34:43 +0200 > From: Alexander Dalloz > Subject: Re: [CentOS] Configure LAGG Interface? > To: centos@centos.org > Message-ID: <50201c53.2070...@uni-x.org> > Content-Type: text/plain; charset=ISO-8859-1 > > Am 06.08.2012 19:44, schrieb Rainer Duffner: >> > >> > Am 06.08.2012 um 19:22 schrieb Cal Sawyer : >> > >>> >> In my experience, LAG/LACP won't provide aggregatation, only failover >>> >> and fault tolerance. For link aggregation, you don't need to configure >>> >> the switch ports - just set bonding to mode=6 for balanced >>> >> transmit/receive and plug up the the NICs to a group of ports on the >>> >> switch. However, balance-alb doesn't help with single stream rsync/FTP >>> >> sessions, etc, but helps a lot with concurrent transmits/receives as >>> >> encountered in typical fileserver scenarios. >>> >> >> > >> > >> > On FreeBSD, you don't get 2*1 Gbit from A to B, but 1*1 Gbit from A to B >> > and another 1*1 Gbit from C to B. >> > "B" being the server with the LAGG interface. Yup, as i said, which isn't too bad (imho). "Real" LAG/LACP can't provide 2x bandwidth for one stream either, can it? >> > >> > How is that in CentOS? > It is of course the same, as long as we speak about standardized 802.3ad > protocol. > > Alexander The nice thing about balance-alb is that you don't have to care (or forget, in my case) about how the switch is configured. Ever come across a switch that "someone else" has set up LAGs on but nobody can remember (or admit) why? ) Throw arpwatch on the bonded-NICs server and see how the bonded interface flips between the slave MACs as intended - cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
