From neo3matrix at gmail.com Thu Nov 1 06:30:01 2012 From: neo3matrix at gmail.com (neo3 matrix) Date: Thu, 1 Nov 2012 12:00:01 +0530 Subject: [rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver? In-Reply-To: <508E9CD1.1090003@oracle.com> References: <508E9CD1.1090003@oracle.com> Message-ID: Thank you Herbert for reply. We do support recovery of one client on other client by doing dissimilar disk mapping from one client to other. For example, for this, what we do in our product is:- Case 1: If I have a guest OS (say GA) on a Xenserver (sayXA). I have 2 disks on GA having host:Id:channel:lun string in /proc/scsi/scsi is as :- 2:0:0:0 and 4.0.1.0 where disks say /dev/sda belongs to 2:0:0:0 and /dev/sdb belongs to 4:0:1:0. Now, if i have another Xenserver (say XB) with a guest OS on it (say GB), then according to my project, I can be to restore GA client on GB, where I can directly map both the disks on GA with disks on GB and do the restore. Of course, it is possible only if :- 1. GB also have 2 or more disks. 2. the disks in GB* MUST* be having exactly same host:id:chaanel:lun as that of disks in GA. That means, disks in GB have 2:0:0:0 and 4:0:1:0 disk locations in its /proc/scsi/scsi. 3. disk size in GB is greater than or equal to disk size in GA. We already have this mechanism working for physical as well as virtual clients having *scsi disks*. But, for /dev/xvdX type of disks which do not have host:id:channel:lun at all, I need some similar mechanism so that I could map disk locations across the clients and restore systems. I understand that, there is a unique string for /dev/xvdX disks i.e. "vbd-XXX". Though it remains same for multiple disks within a system, it is different for multiple clients on multiple Xenservers according to their settings. So, Can you tell me a way out to map disks on different systems? Regards, Neo On Mon, Oct 29, 2012 at 8:42 PM, Herbert van den Bergh < herbert.van.den.bergh at oracle.com> wrote: > > The hardware mapping is not going to be deterministic between servers. So > you need to rely on some unique identifier stored in the contents of the > virtual disks. Which one you can use depends on how you backup and restore > your virtual disks. Where does your DR restore run? In domU or in dom0? > And how exactly do you backup and restore the virtual disks? > > Thanks, > Herbert. > > > On 10/29/12 12:19 AM, neo3 matrix wrote: > > Thank you John and Grzegorz for your quick replies. > Sorry for late reply (as I was not in town). > > Basically, I am working on a Disaster Recovery software whose disk logic > is totally dependent on disk mapping . > > Even in my project, I should be able to map a disk from one OS on > Xenserver to other OS on other Xenserver. > > So, as John suggested, > >>> "The good news with Xen disks is that they really do have > deterministic slots. The virtual disk in slot xvdb will >>> always be > xvdb (the "vbd-NNN" numbers simply refer to event channels." > Here, I can't use vbd-XXX names as they differ from one guest OS to other > and one Xenserver to other. > Also, changing the Xenserver setting in VM definition file is in > customer's hand which I cannot control. > > I can't try UUID as well for disk mapping because the problem is during > disaster recovery process we used to repartition disks and due to that UUID > of disk and partitions gets changed. > > So, to map disks from one xenserver to other, I need some mapping > mechanism like host:channel:id:lun > OR > the way "lscsci" command gives output which is similar in other Xenserver > as well and I can be able to map disks. > > Can you please help me out in the same? > > Thank you for your valuable suggestions. > > Regards, > Neo > > > > > On Fri, Oct 19, 2012 at 1:08 PM, John Haxby wrote: > >> >> >> On 19 October 2012 07:32, neo3 matrix wrote: >> >>> Hi all, >>> >>> I have installed RHEL6 as guest OS on Citrix Xen Server. After >>> installation of OS, I can see disk names as /dev/xvda, /dev/xvdb instead of >>> traditional convention like /dev/sda, /dev/sdb on guest OS. >>> >>> Generally, on physical machines, in /proc/scsi/scsi file, we get a >>> unique entry for every disk connected to the system. For e.g. string >>> "scsi02:00:00:01" indicates that this disk is connected to the machine via >>> Host=2, Channel=00, Id=00 Lun=01. This helps me in my project to uniquely >>> identify each and every disk in scenarios where many times after reboot OR >>> in SAN boot cases OR in some Disaster Recovery procedures, disk names might >>> change from say /dev/sda to /dev/sdb after reboot. But, this >>> Host:Channel:ID:Lun combination remains same for every disk and I can >>> uniquely identify the disks though their /dev/sd* names have changed. >>> >>> For my project, on Citrix Xenserver, I need to know the unique disk >>> location for such Xen guest OS devices by which I can easily identify disks >>> across the reboots for the above mentioned cases. >>> >>> >> >> Oooh. Complicated question. >> >> To start with, those SCSI-type disk identifiers are not as deterministic >> as you might hope. "Host=2" merely refers to the SCSI controller that was >> discovered at position number 2. These days, discovery order counts for >> nothing: devices are discovered and initialised concurrently, more or less, >> so while you might get devices discovered in the "right" order almost all >> the time, you might find that powering on a machine on a particularly cold >> morning changes the order in which things are discovered. Even worse, if >> what used to be /dev/sdb goes AWOL then you're not left with a hole in the >> sequence, everything from what used to be /dev/sdc onwards gets renamed. >> >> The good news with Xen disks is that they really do have deterministic >> slots. The virtual disk in slot xvdb will always be xvdb (the "vbd-NNN" >> numbers simply refer to event channels, they aren't random but they might >> as well be). You would need to edit the VM definition in the host to >> change the virtual disks. >> >> Even more good news: you don't need to use the /dev/sdX, /dev/xvdX, etc >> names at all. >> >> If you look in /dev/disk you'll find several directories. The one you're >> probably most interested in is /dev/disk/by-uuid: entries in /etc/fstab >> should be using the UUID= format to identify things that aren't logical >> volumes (logical volumes are named within their volume group and the >> physical volumes that make up a volume group aren't tied to specific >> devices although they do have specific UUIDs). >> >> Running "blkid" (as root) is quite useful as well. >> >> jch >> >> _______________________________________________ >> rhelv6-list mailing list >> rhelv6-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rhelv6-list >> > > > > _______________________________________________ > rhelv6-list mailing listrhelv6-list at redhat.comhttps://www.redhat.com/mailman/listinfo/rhelv6-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.haxby at gmail.com Thu Nov 1 09:07:17 2012 From: john.haxby at gmail.com (John Haxby) Date: Thu, 1 Nov 2012 09:07:17 +0000 Subject: [rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver? In-Reply-To: References: <508E9CD1.1090003@oracle.com> Message-ID: On 1 November 2012 06:30, neo3 matrix wrote: > So, Can you tell me a way out to map disks on different systems? > > > Basically, you can't. Hardware discovery is not deterministic. There's no reason why sda and sdb (say) should be assigned to the same physical disk on successive reboots of a single machine. If you're moving disks to a different machine, even if it's an identical machine with the controllers in the same slots there's even less chance. You cannot ever rely on /dev/sda being a particular disk. Period. I'm sure I said that before. What you need are the UUIDs that identify specific file systems and partitions, these do not change because they're actually on the media so it doesn't matter where the disk is plugged in, it will always be the same and it will always be unique. jch -------------- next part -------------- An HTML attachment was scrubbed... URL: From lowen at pari.edu Thu Nov 1 13:55:10 2012 From: lowen at pari.edu (Lamar Owen) Date: Thu, 1 Nov 2012 09:55:10 -0400 Subject: [rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver? In-Reply-To: References: Message-ID: <201211010955.10719.lowen@pari.edu> On Thursday, November 01, 2012 05:07:17 AM John Haxby wrote: > On 1 November 2012 06:30, neo3 matrix wrote: > > So, Can you tell me a way out to map disks on different systems? > > Basically, you can't. Hardware discovery is not deterministic. There's > no reason why sda and sdb (say) should be assigned to the same physical > disk on successive reboots of a single machine. If you're moving disks to > a different machine, even if it's an identical machine with the controllers > in the same slots there's even less chance. You cannot ever rely on > /dev/sda being a particular disk. Period. Let me echo this. I have a smallish RHEL 6.3 test server with several disk controllers: the boot device is a 3Ware 9500S-LP SATA RAID; then there's a couple of internal 750GB SATA disks (set as software RAID1) on a four port (two internal ports and two external ports, which get frequent use) controller; there's also an internal Adaptec U160 SCSI port on the motherboard; also there are two PATA ports and an IDE drive sled; and there's a two port fibre channel HBA connected to a fully HA (full dual fabric, dual attach each fabric) three EMC Clariion CX3 and CX4 arrays. This is, after all a test server, and it gets a lot of use in that capacity, especially when it comes to data recovery from IDE, SATA, and USB drives, along with FC LUNs if something goes wrong filesystem-wise; it's a snap with EMC to take a LUN from one server's storage group and throw it onto the test server's storage group, rescan the scsi bus, and do diagnostics with the test server. I've seen the (booting) 3Ware logical drive show at /dev/sda; and I've seen it show up as /dev/sdu, and I've seen it as /dev/sdab, and it's today residing at: [root at www ~]# mount |grep boot /dev/mapper/mpathkp1 on /boot type ext4 (rw) [root at www ~]# multipath -l /dev/mapper/mpathk mpathk (1AMCC 4ND1Q84S1FA203004634) dm-18 AMCC,9500S-4LP DISK size=698G features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=0 status=active `- 10:0:0:0 sdac 65:192 active undef running [root at www ~]# uname -srv Linux 2.6.32-279.9.1.el6.i686 #1 SMP Fri Aug 31 09:03:11 EDT 2012 [root at www ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.3 (Santiago) [root at www ~]# (yeah, I know, multipath on it is a tad useless, but this is the default setting for multipathd, as I haven't blacklisted any devices in my multipath config; this is, after all, a test server.....). >From one bootup to the next /boot's device will and does change. It is not predictable, and that's OK, thanks to the way /etc/fstab is set up in EL6. If you rely on /dev/sdX being constant or even predictable on EL6 you're in for a rude awakening. From herbert.van.den.bergh at oracle.com Thu Nov 1 15:07:50 2012 From: herbert.van.den.bergh at oracle.com (Herbert van den Bergh) Date: Thu, 01 Nov 2012 08:07:50 -0700 Subject: [rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver? In-Reply-To: <201211010955.10719.lowen@pari.edu> References: <201211010955.10719.lowen@pari.edu> Message-ID: <50929046.9090602@oracle.com> On 11/1/12 6:55 AM, Lamar Owen wrote: > On Thursday, November 01, 2012 05:07:17 AM John Haxby wrote: >> On 1 November 2012 06:30, neo3 matrix wrote: >>> So, Can you tell me a way out to map disks on different systems? >> Basically, you can't. Hardware discovery is not deterministic. There's >> no reason why sda and sdb (say) should be assigned to the same physical >> disk on successive reboots of a single machine. If you're moving disks to >> a different machine, even if it's an identical machine with the controllers >> in the same slots there's even less chance. You cannot ever rely on >> /dev/sda being a particular disk. Period. > Let me echo this. [snip] > If you rely on /dev/sdX being constant or even predictable on EL6 you're in > for a rude awakening. > This is all very true for bare metal machines. But Neo was talking about XenServer guests. Those do have deterministic device names. The host may not, but that's a different issue. I'm assuming he's talking about the scsi address that the guest OS reports, not the host. Which is weird, because why would you bother with a scsi address if you know that the device name is deterministic. If the user can map the virtual disks on server A to server B, why not do the restore on the server instead of in the guest? If the disks that are being restored are OS disks, the guest can't boot from them. So how does the restore get started in the guest? Via pxeboot or something? Why bother with this, when you can just do this in dom0 with a simple cp or dd command. Thanks, Herbert. From janfrode at tanso.net Sat Nov 3 11:08:42 2012 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Sat, 3 Nov 2012 12:08:42 +0100 Subject: [rhelv6-list] java-1.6.0-sun In-Reply-To: <507F0932.5050205@umiacs.umd.edu> References: <507F0932.5050205@umiacs.umd.edu> Message-ID: On Wed, Oct 17, 2012 at 9:38 PM, Derek Yarnell wrote: > Hi, > > Does anyone know if this package is no longer going to be updated? > Neither of the last two java updates (RHSA-2012:1384/1385 or > RHSA-2012:1221/1222) have released packages specifically for > java-1.6.0-sun. Have you checked RHSA-2012-1392 ? -jf From santi at woop.es Wed Nov 7 16:29:35 2012 From: santi at woop.es (Santi Saez) Date: Wed, 07 Nov 2012 17:29:35 +0100 Subject: [rhelv6-list] Different behavior of net.ipv4.ip_local_port_range between RHEL-5 and RHEL-6 Message-ID: <509A8C6F.4030000@woop.es> Hello, Just found that net.ipv4.ip_local_port_range has different behavior between RHEL releases: until v6 although you have multiple source IPs you can only use a fixed number of local ports, seems that "ip_local_port_range" is a global configuration or limitation. On RHEL-6 kernel (testing with 2.6.32-279) you can bind() to N local ports per source IP, it's a per-IP limit: total ports = ip_local_port_range x source IP. The problem is that on RHEL-5 and 4 you can only make ip_local_port_range outgoing connections and you can't use different source IPs trick to increase this limitation. I have been testing and vanilla 2.6.32 kernel and other Linux distributions like Debian doesn't support this. What has been changed/patched on RHEL-6 to allow this? thanks! Santi Saez From thomas.cameron at camerontech.com Thu Nov 8 19:29:29 2012 From: thomas.cameron at camerontech.com (Thomas Cameron) Date: Thu, 08 Nov 2012 13:29:29 -0600 Subject: [rhelv6-list] Weird issue with iptables Message-ID: <509C0819.4010501@camerontech.com> I have set up a RHEL 6 firewall. There are two basically identical machines behind the firewall. One can get to the Internet just fine, the other can only get to some sites. Other sites are very slow - like several minutes to load a page. It's very weird. If the affected box tries to go to e.g. www.yahoo.com, it gets the first part of the page, then hangs for several minutes while it loads super slowly. The weird thing is, if the affected machine goes to any google.com address, it works fine. Now, the working machine resolves e.g. www.yahoo.com to a different address from the broken machine because of content deliver network addressing. The network is connected via Time Warner business class service, and I have 5 usable IP addresses, in the range 24.99.99.0/255.255.255.248. It has two physical interfaces, 24.99.99.5 (eth1, external, public) and 10.0.2.1 (eth0, internal, private). I have several virtual interfaces, 24.99.99.2, 24.99.99.3, 24.99.99.4, and 24.99.99.6 (eth1:0 through eth1:3). I've poked holes through the firewall with DNAT so I can remote desktop to a couple of Windows boxes, allow web traffic in, ssh to a Linux box, allow e-mail to the spam filtering box, etc. My firewall rules look like this: [root at office ~]# service iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination Table: nat Chain PREROUTING (policy ACCEPT) num target prot opt source destination 1 DNAT tcp -- 0.0.0.0/0 24.99.99.2 tcp dpt:80 to:10.0.2.2 2 DNAT tcp -- 0.0.0.0/0 24.99.99.2 tcp dpt:443 to:10.0.2.2 3 DNAT tcp -- 0.0.0.0/0 24.99.99.2 tcp dpt:3389 to:10.0.2.2 4 DNAT tcp -- 0.0.0.0/0 24.99.99.2 tcp dpt:53 to:10.0.2.20 5 DNAT udp -- 0.0.0.0/0 24.99.99.2 udp dpt:53 to:10.0.2.20 6 DNAT tcp -- 0.0.0.0/0 24.99.99.2 tcp dpt:22 to:10.0.2.201 7 DNAT tcp -- 0.0.0.0/0 24.99.99.2 tcp dpt:25 to:10.0.2.201 8 DNAT tcp -- 0.0.0.0/0 24.99.99.3 tcp dpt:3389 to:10.0.2.3 9 DNAT tcp -- 0.0.0.0/0 24.99.99.3 tcp dpt:80 to:10.0.2.140 10 DNAT tcp -- 0.0.0.0/0 24.99.99.3 tcp dpt:6036 to:10.0.2.140 11 DNAT tcp -- 0.0.0.0/0 24.99.99.4 tcp dpt:53 to:10.0.2.20 12 DNAT udp -- 0.0.0.0/0 24.99.99.4 udp dpt:53 to:10.0.2.20 13 DNAT tcp -- 0.0.0.0/0 24.99.99.5 tcp dpt:80 to:10.0.2.13 14 DNAT tcp -- 0.0.0.0/0 24.99.99.5 tcp dpt:443 to:10.0.2.13 15 DNAT tcp -- 0.0.0.0/0 24.99.99.6 tcp dpt:3389 to:10.0.2.6 Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 SNAT all -- 10.0.2.0/24 !10.0.2.0/24 to:24.99.99.5 Chain OUTPUT (policy ACCEPT) num target prot opt source destination The two systems I am looking at are at 10.0.2.3 (broken internet access) and 10.0.2.6 (internet works fine). Both are Windows machines. I'm at a loss as to what I've done wrong. Why would some machines get incredibly slow responses but others are snappy? Thomas Cameron From paul at mad-scientist.net Thu Nov 8 21:24:53 2012 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 08 Nov 2012 16:24:53 -0500 Subject: [rhelv6-list] Problems with XFS leaving 0-length files in RHEL 6.2 ... ? In-Reply-To: <1350138443.10588.60.camel@homebase> References: <1350138443.10588.60.camel@homebase> Message-ID: <1352409893.9281.16.camel@homebase> On Sat, 2012-10-13 at 10:27 -0400, Paul Smith wrote: > On Sat, 2012-10-13 at 05:53 +0000, Edmund White wrote: > > What are the names of these files? Can you see when these files are > > created? This may not be an XFS-specific issue. Hi all. Back again with this problem. For a while we were busy with other things and we didn't see this problem so much but now it's back with a vengeance and I need to work out the fix or a workaround. I've managed to determine that on one of my systems I had this problem happen (back on Oct 23!) It appears that all of these failures (that I've seen so far) are associated with a kernel panic or reboot of some kind. I created a cron job that runs hourly looking for 0-length files, and I discovered the introduction of a whole bunch of them between 8am and 9am on Oct 23: # wc -l findzero.20121023080101 findzero.20121023090102 400 findzero.20121023080101 789 findzero.20121023090102 within that hour, 389 0-length files were created. I looked at these files and they included programs (executables) that had been installed on the system the day before, Oct 22 at about 11am, over 18 hours previously. The timestamps on these files were still set to the Oct 22 time. Obviously, as programs, they will not be opened for writing (just opened for read by the runtime linker when executed). I checked the logs for these programs and they were successfully invoked AFTER they were installed, but were not being used anywhere close to the hour in question (these are command line tools, not daemons, and they write to a log every time they are used). I looked at /var/log/messages and sure enough, at 8:09am I see that my system started to have some trouble: Oct 23 08:09:12 kernel: eth1: Link down Oct 23 08:09:12 kernel: bonding: bond0: link status definitely down for interface eth1, disabling it Oct 23 08:09:42 kernel: eth1: Link up Oct 23 08:09:42 kernel: bond0: link status definitely up for interface eth1, 10000 Mbps full duplex. Oct 23 08:09:48 kernel: eth0: Link down Oct 23 08:09:48 kernel: bonding: bond0: link status definitely down for interface eth0, disabling it Oct 23 08:10:01 kernel: Uhhuh. NMI received for unknown reason 3d on CPU 0. Oct 23 08:10:01 kernel: Do you have a strange power saving mode enabled? Oct 23 08:10:01 kernel: Dazed and confused, but trying to continue Then the next thing in the log is the beginning of a new kernel boot, so obviously the system went down here: Oct 23 08:15:57 kernel: imklog 4.6.2, log source = /proc/kmsg started. Oct 23 08:15:57 rsyslogd: [origin software="rsyslogd" swVersion="4.6.2" x-pid="2512" x-info="http://www.rsyslog.com"] (re)start etc. This seems bad to me. I can accept that in the event of a kernel panic or system crash, some files that are "in flight" might be zero'd out. But I can't accept that it's OK to have almost 400 files that were written 18 hours before and, all evidence shows, were not being actively used when the crash happened, would be zero'd out like this. Surely this cannot be "just the price we pay"? I'm looking at the kernel panic separately (seems to be a common thing as well) but I need the filesystem to be more stable than this in any event. Anyone have any ideas? From lists at brimer.org Fri Nov 9 22:26:19 2012 From: lists at brimer.org (Barry Brimer) Date: Fri, 09 Nov 2012 16:26:19 -0600 Subject: [rhelv6-list] Weird issue with iptables In-Reply-To: <509C0819.4010501@camerontech.com> References: <509C0819.4010501@camerontech.com> Message-ID: <1352499979.509d830be7bd9@mail.toucanhost.com> > The two systems I am looking at are at 10.0.2.3 (broken internet access) > and 10.0.2.6 (internet works fine). Both are Windows machines. > > I'm at a loss as to what I've done wrong. Why would some machines get > incredibly slow responses but others are snappy? Have you tried running ntop on the firewall? That might help identify some network weirdness. You also might try making hosts file entries for the working Yahoo! server on the non-working box and see if the problem follows. Along the same lines, you could switch IP addresses on the Windows machines and see if the problem follows the IP address or not. You could also change switch ports, LAAs or even NICs to try and isolate. If all else fails, Wireshark is your friend. Hope this helps, Barry From paul at mad-scientist.net Fri Nov 9 23:12:44 2012 From: paul at mad-scientist.net (Paul Smith) Date: Fri, 09 Nov 2012 18:12:44 -0500 Subject: [rhelv6-list] Problems with XFS leaving 0-length files in RHEL 6.2 ... ? In-Reply-To: <1352409893.9281.16.camel@homebase> References: <1350138443.10588.60.camel@homebase> <1352409893.9281.16.camel@homebase> Message-ID: <1352502764.28593.17.camel@psmithlab.usma.ibm.com> On Thu, 2012-11-08 at 16:24 -0500, Paul Smith wrote: > On Sat, 2012-10-13 at 10:27 -0400, Paul Smith wrote: > > On Sat, 2012-10-13 at 05:53 +0000, Edmund White wrote: > > > What are the names of these files? Can you see when these files are > > > created? This may not be an XFS-specific issue. > > Hi all. Back again with this problem. For a while we were busy with > other things and we didn't see this problem so much but now it's back > with a vengeance and I need to work out the fix or a workaround. I believe that I'm running into an issue resolved by this errata, published just a couple of weeks ago: http://rhn.redhat.com/errata/RHSA-2012-1401.html I'm testing it now to be sure it really fixes the problem (I don't have a perfect way to reproduce it so it's not so simple; the bug report is private so I can't see the details). FYI... From thomas.cameron at camerontech.com Sat Nov 10 05:10:22 2012 From: thomas.cameron at camerontech.com (Thomas Cameron) Date: Fri, 09 Nov 2012 23:10:22 -0600 Subject: [rhelv6-list] Weird issue with iptables In-Reply-To: <1352499979.509d830be7bd9@mail.toucanhost.com> References: <509C0819.4010501@camerontech.com> <1352499979.509d830be7bd9@mail.toucanhost.com> Message-ID: <509DE1BE.1010104@camerontech.com> On 11/09/2012 04:26 PM, Barry Brimer wrote: >> The two systems I am looking at are at 10.0.2.3 (broken internet access) >> and 10.0.2.6 (internet works fine). Both are Windows machines. >> >> I'm at a loss as to what I've done wrong. Why would some machines get >> incredibly slow responses but others are snappy? > > Have you tried running ntop on the firewall? That might help identify some > network weirdness. You also might try making hosts file entries for the > working Yahoo! server on the non-working box and see if the problem follows. > Along the same lines, you could switch IP addresses on the Windows machines and > see if the problem follows the IP address or not. You could also change switch > ports, LAAs or even NICs to try and isolate. If all else fails, Wireshark is > your friend. I used traceroute, tcpdump and several other tools and got nothing. On a whim, I installed Firefox and it was back to being blazing fast. I dug around in the internet "security" settings for IE and turned off "protected mode." That seems to have fixed it. The fact that this happened after I put in the Linux firewall appears to be a coincidence. Sorry for the noise. TC From b.j.smith at ieee.org Sat Nov 10 05:41:06 2012 From: b.j.smith at ieee.org (Bryan J Smith) Date: Sat, 10 Nov 2012 00:41:06 -0500 Subject: [rhelv6-list] Weird issue with iptables In-Reply-To: <509C0819.4010501@camerontech.com> References: <509C0819.4010501@camerontech.com> Message-ID: Thomas Cameron wrote: > ... The network is connected via (ISP censored) business class service ... I assume you are in Texas? I've been doing some testing over the last year with my local ISP (same ISP as you ;) servers in the Virginias and there have been times where I've just lost resolution, both primary and secondary IPs. As such, I've actually setup a simple polling script test access to port 53 of the primary and secondary. When they fail I change to Google's DNS, which only has the downside of not being as regionally resolving (i.e., I find it won't always give me the most local Aikami and other content servers). Just some considerations, since you mentioned the same ISP. Some of their tech support has actually been very receptive to information I've provided. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith ---------------------------------------------------------- Computers are precise, but not accurate, and make mistakes due to lack of input, as lack of awareness and observation From workmam at kramergraphics.com Mon Nov 12 14:47:20 2012 From: workmam at kramergraphics.com (Mark Workman) Date: Mon, 12 Nov 2012 09:47:20 -0500 Subject: [rhelv6-list] csh question Message-ID: <6DA0DB5CB23FA3428C2B7BDD38983A19854F3C@kgexchange.KramerGraphics.Com> We received this info a software vendor (below). I can't find anything about this patch on Redhat's web site. Does anyone know where I might find this patch? We are running RES6.3 2.6.32-262.el6.x86_64 csh --version returns tcsh-6.17.00 /bin/csh is linked to /bin/tcsh Any tips or guidance is greatly appreciated. Mark ----------------------------------------------------------- This is a problem with /bin/csh. I don't have much more detail than to say that /bin/csh needs to be patched. Another customer saw this and also found that RedHat has a fix for it. A more specific description of the issue is: It does not return the correct exit status from commands run inside `backquotes`. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsbillin at umich.edu Mon Nov 12 15:11:50 2012 From: jsbillin at umich.edu (Jonathan Billings) Date: Mon, 12 Nov 2012 10:11:50 -0500 Subject: [rhelv6-list] csh question In-Reply-To: <6DA0DB5CB23FA3428C2B7BDD38983A19854F3C@kgexchange.KramerGraphics.Com> References: <6DA0DB5CB23FA3428C2B7BDD38983A19854F3C@kgexchange.KramerGraphics.Com> Message-ID: On Mon, Nov 12, 2012 at 9:47 AM, Mark Workman wrote: > We received this info a software vendor (below). I can?t find anything about > this patch on Redhat?s web site. Does anyone know where I might find this > patch? > > We are running RES6.3 2.6.32-262.el6.x86_64 > > csh ?-version returns tcsh-6.17.00 /bin/csh is linked to /bin/tcsh > > Any tips or guidance is greatly appreciated. > > Mark > > ----------------------------------------------------------- > > This is a problem with /bin/csh. I don't have much more detail than to say > that /bin/csh needs to be patched. Another customer saw this and also found > that RedHat has a fix for it. > > > > A more specific description of the issue is: It does not return the correct > exit status from commands run inside `backquotes`. This appears to have been fixed in RHBA-2012:0687 (https://rhn.redhat.com/rhn/errata/details/Details.do?eid=15602). You probably need to update your 'tcsh' package to version 6.17-16 or later. -- Jonathan Billings College of Engineering - CAEN - Unix and Linux Support From john.haxby at gmail.com Mon Nov 12 15:14:35 2012 From: john.haxby at gmail.com (John Haxby) Date: Mon, 12 Nov 2012 15:14:35 +0000 Subject: [rhelv6-list] csh question In-Reply-To: <6DA0DB5CB23FA3428C2B7BDD38983A19854F3C@kgexchange.KramerGraphics.Com> References: <6DA0DB5CB23FA3428C2B7BDD38983A19854F3C@kgexchange.KramerGraphics.Com> Message-ID: On 12 November 2012 14:47, Mark Workman wrote: > We are running RES6.3 2.6.32-262.el6.x86_64**** > > csh ?-version returns tcsh-6.17.00 /bin/csh is linked to /bin/tcsh**** > > Any tips or guidance is greatly appreciated.**** > > The kernel version isn't of much interest except that you're probably running something a little old (2.6.32-279... is current). The csh/tcsh version also isn't terribly useful, what *is* useful is rpm -q tcsh and rpm -q tcsh --changelog shows, among other things: * Mon Feb 20 2012 Vojtech Vitek (V-Teq) - 6.17-16 - Revert exit status regression with it's opt-out variable $anyerror, added by "Fix status of pipelined/backquoted/list of commands" and opt-in the POSIX-like exit status behaviour by $status_posix_value variable instead (#784510) and that number is the bugzilla for this problem. jch -------------- next part -------------- An HTML attachment was scrubbed... URL: From workmam at kramergraphics.com Mon Nov 12 15:21:38 2012 From: workmam at kramergraphics.com (Mark Workman) Date: Mon, 12 Nov 2012 10:21:38 -0500 Subject: [rhelv6-list] csh question Message-ID: <6DA0DB5CB23FA3428C2B7BDD38983A19854F3D@kgexchange.KramerGraphics.Com> On Mon, Nov 12, 2012 at 9:47 AM, Mark Workman wrote: > We received this info a software vendor (below). I can?t find anything > about this patch on Redhat?s web site. Does anyone know where I might > find this patch? > We are running RES6.3 2.6.32-262.el6.x86_64 > csh ?-version returns tcsh-6.17.00 /bin/csh is linked to /bin/tcsh > Any tips or guidance is greatly appreciated. > Mark > ----------------------------------------------------------- > This is a problem with /bin/csh. I don't have much more detail than > to say that /bin/csh needs to be patched. Another customer saw this > and also found that RedHat has a fix for it. > > A more specific description of the issue is: It does not return the > correct exit status from commands run inside `backquotes`. This appears to have been fixed in RHBA-2012:0687 (https://rhn.redhat.com/rhn/errata/details/Details.do?eid=15602). You probably need to update your 'tcsh' package to version 6.17-16 or later. -- Jonathan Billings College of Engineering - CAEN - Unix and Linux Support Will do this. Thanks for the quick help. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From workmam at kramergraphics.com Mon Nov 12 15:31:58 2012 From: workmam at kramergraphics.com (Mark Workman) Date: Mon, 12 Nov 2012 10:31:58 -0500 Subject: [rhelv6-list] rhelv6-list Digest, Vol 25, Issue 6 References: Message-ID: <6DA0DB5CB23FA3428C2B7BDD38983A19854F3E@kgexchange.KramerGraphics.Com> The kernel version isn't of much interest except that you're probably running something a little old (2.6.32-279... is current). The csh/tcsh version also isn't terribly useful, what *is* useful is rpm -q tcsh and rpm -q tcsh --changelog shows, among other things: * Mon Feb 20 2012 Vojtech Vitek (V-Teq) - 6.17-16 - Revert exit status regression with it's opt-out variable $anyerror, added by "Fix status of pipelined/backquoted/list of commands" and opt-in the POSIX-like exit status behaviour by $status_posix_value variable instead (#784510) and that number is the bugzilla for this problem. jch ------------------------ I see the difference in the commands. I'll use rpm instead. Thanks for the help. From rda at rincon.com Mon Nov 12 23:20:42 2012 From: rda at rincon.com (Bob Arendt) Date: Mon, 12 Nov 2012 16:20:42 -0700 Subject: [rhelv6-list] csh question In-Reply-To: <6DA0DB5CB23FA3428C2B7BDD38983A19854F3D@kgexchange.KramerGraphics.Com> References: <6DA0DB5CB23FA3428C2B7BDD38983A19854F3D@kgexchange.KramerGraphics.Com> Message-ID: <50A1844A.7080400@rincon.com> On 11/12/12 08:21, Mark Workman wrote: > On Mon, Nov 12, 2012 at 9:47 AM, Mark Workman > wrote: > >> We received this info a software vendor (below). Ican?t find anything > >> about this patch onRedhat?s web site. Does anyone know where I might > >> find this patch? > >> We are running RES6.32.6.32-262.el6.x86_64 > >>csh ?-version returns tcsh-6.17.00/bin/csh is linked to /bin/tcsh > >> Any tips or guidance is greatly appreciated. > >> Mark > >> ----------------------------------------------------------- > >> This is a problem with /bin/csh.I don't have much more detail than > >> to say that /bin/csh needs to be patched.Another customer saw this > >> and also found thatRedHat has a fix for it. > >> > >> A more specific description of the issue is: It does not return the > >> correct exit status from commands run inside `backquotes`. > > This appears to have been fixed in RHBA-2012:0687 > (https://rhn.redhat.com/rhn/errata/details/Details.do?eid=15602). > > You probably need to update your 'tcsh' package to version 6.17-16 or later. > > -- > > Jonathan Billings > > > College of Engineering - CAEN - Unix and Linux Support > > Will do this. Thanks for the quick help. > > Mark > > However, the current release has a bug that breaks a lot of legacy scripts: source command fails with single-line if-statement https://bugzilla.redhat.com/show_bug.cgi?id=847102 This bugzilla has a couple of patches (either remove the broken patch, or there's an attached patch file that corrects the actual problem. The previous bug where RedHat changed the pipe status to make more posix-like (really? csh?) was bug 658190. If desired, the posix-like behavior can be enabled with a "set" variable. Cheers, -Bob Arendt From dgerow at afflictions.org Mon Nov 19 16:07:39 2012 From: dgerow at afflictions.org (Damian Gerow) Date: Mon, 19 Nov 2012 11:07:39 -0500 Subject: [rhelv6-list] IPsec Endpoint Failover/Redundancy Message-ID: <20121119160739.GD20895@wolfman.devio.us> We're connecting a handful of remote leaf nodes back to a central network via IPsec, but we seem to have run into a problem with redundancy and failover. I'm wondering if I can get an idea of what other people are doing for IPsec and failover, and maybe figure out a way to stabilize our tunnels. It's been a while since I've played with IPsec, so my grasp of most of these concepts is fairly weak. I find myself getting lost in the various bits of documentation, and it seems that available docs on OpenS/WAN and NETKEY (the implementation used in RHEL6?) are minimal. While there are lots of configuration examples, there's not much covering terminology, and many of the options for the 'ipsec' binary don't seem to be available for NETKEY. Configuration: We've kept it as simple as possible. The remote nodes need to communicate with two local nodes, so we have two host-to-host tunnels configured. RSA is used for authentication, and to work around various firewalls in the communications path, we've had to enable NAT-T (even though no NAT is being used). Main mode is used everywhere, as well as DPD with an action of 'restart'. The problems: 1) The local 'endpoint' is actually two machines that handle failover via ucarp. Unfortunately, pluto doesn't seem to like having its interfaces change underneath it, meaning pluto needs to be stopped/started in vip-down and vip-up, respectively. Alternatively, don't terminate on a VIP at all, and figure out another way to route it on the remote endpoints. 2) Occasionally, we've seen the VIP be removed from the interface when running 'service ipsec restart'. It seems to be fine with a manual stop/start. ucarp itself doesn't log anything, and we're unclear as to why/how this happens (no logs). 3) There are times when the local endpoint gets into a situation where 'service ipsec status' reports >5x the number of configured tunnels. Looking at 'ipsec whack --status', it looks like there are multiple SAs (both IPsec and ISAKMP) established per remote endpoint This appears to be fine, as there are times when the tunnels continue to operate properly, but we've seen situations where the endpoint is unable/unwilling to use any of the SAs, and does not respond to DPD R_U_THERE packets. 4) We've seen regular occurrences where the remote endpoint believes the tunnel is up, and the local endpoint believes the tunnel is down, and they're unable to come to a mutually-beneficial agreement. This was when we ran with 'dpdaction=clear' on the local endpoint, and have since moved to 'restart' to fix this. Unfortunately, it seems that at times the local endpoint holds on to the route for the remote endpoint even when the SA is cleared, possibly resulting in problem #3 above: DPD fails from the local endpoint, causing it to renegotiate the SA, but the route remains broken, causing the new SA to fail DPD, etc. NB: this is just a theory -- I don't know how to IPsec. I'm about to work towards managing ipsec from ucarp, where the service is stopped and started as is appropriate via vip-up/vip-down. This is largely to address problem #1, which seems otherwise insurmountable (possibly routing the VIP over one tunnel), but may end up resolving some of our other issues. But before I do this, I figured I'd ask: How are other people handling ipsec endpoint failovers? Is there a 'best' way to access a floating virtual IP, where 'overlapip' doesn't seem to be available (KLIPS/mast only), and 'modecfg*' doesn't seem to offer an option for routing? From S.Reber at lcsys.ch Thu Nov 22 09:10:20 2012 From: S.Reber at lcsys.ch (Simon Reber) Date: Thu, 22 Nov 2012 09:10:20 +0000 Subject: [rhelv6-list] bonding setup in RHEL6 Message-ID: Hi list, I'm a bit confused about the bonding setup in RHEL6. Some time ago I experienced difficulties configure bonding on RHEL6! Then I found that instead of "alias bond0 bonding" one should use "alias netdev-bond0 bonding" instead. Now I have several servers configured using "alias netdev-bond0 bonding" and they work just perfect. But last week we migrated a server to a new datacenter where we have the ability to configure bonding. We configured the server using "alias netdev-bond0 bonding" and bonding failed. We then switched back to "alias bond0 bonding" and bonding started working immediately! Please note that all our servers are running the same patch level of RHEL6.2 - so there is no way that we have any difference between patch levels Looking at the documentation I see lots of information about "netdev, bonding, etc." - but the RHEL 6 documentation says that one should use "alias bond0 bonding": https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-interfaces-chan.html https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec-Using_Channel_Bonding.html So I was wondering if someone could probably shed some light on that topic as it is very unclear to me (https://access.redhat.com/knowledge/solutions/56496) Thanks and all the best, Si From David.Kinzel at encana.com Thu Nov 22 14:52:01 2012 From: David.Kinzel at encana.com (Kinzel, David) Date: Thu, 22 Nov 2012 14:52:01 +0000 Subject: [rhelv6-list] bonding setup in RHEL6 In-Reply-To: References: Message-ID: >-----Original Message----- >From: rhelv6-list-bounces at redhat.com [mailto:rhelv6-list- >bounces at redhat.com] On Behalf Of Simon Reber >Sent: Thursday, November 22, 2012 2:10 AM >To: 'rhelv6-list at redhat.com' >Subject: [rhelv6-list] bonding setup in RHEL6 > >Hi list, > >I'm a bit confused about the bonding setup in RHEL6. >Some time ago I experienced difficulties configure bonding on RHEL6! > >Then I found that instead of "alias bond0 bonding" one should use "alias >netdev-bond0 bonding" instead. >Now I have several servers configured using "alias netdev-bond0 bonding" >and they work just perfect. > For what it's worth we don't specify either. We just use BONDING_OPTS in the ifcfg files and let it sort itself out. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com From dgerow at afflictions.org Thu Nov 29 12:53:07 2012 From: dgerow at afflictions.org (Damian Gerow) Date: Thu, 29 Nov 2012 07:53:07 -0500 Subject: [rhelv6-list] Password Hashing and Rounds Message-ID: <20121129125307.GE20895@wolfman.devio.us> I've just spent the morning trying to familiarize myself a bit more with password management, as it relates to the hashing algorithm, and the impact of changing the number of rounds. I've learned a fair bit, but there's one thing outstanding that I'm a bit puzzled over: login.defs and libuser.conf both support parameters that impact the number of rounds, but nothing seems to pay attention to them. pam_unix supports a 'rounds=' parameter, and this does alter password hashing behaviours. However, 'authconfig' does *not* have an option/parameter for 'rounds', so any time it is run, it will over-write the manually-configured 'rounds=' option passwd to pam_unix. Is there a reason that 'authconfig' doesn't support setting the number of rounds? Or that the rounds options set in login.defs and/or libuser.conf are ignored?