Re: [CentOS] Transparent GNOME Terminal in CentOS 7?
Le 24/02/2015 13:51, Jim Perrin a écrit : Might also be worth mentioning that supposedly around the 7.2 timeframe, gnome is scheduled to be bumped to a more modern version. https://bugzilla.redhat.com/show_bug.cgi?id=1174442 In theory this should put transparent terminal support back in gnome-terminal. This is great news. Thanks for the heads-up. In my humble opinion, KDE deserves a similar bump to 4.14, the latest 4.x release. Cheers, Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 120, Issue 9
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CESA-2015:0265 Critical CentOS 6 firefox Security Update
(Johnny Hughes)
2. CESA-2015:0265 Critical CentOS 5 firefox Security Update
(Johnny Hughes)
3. CESA-2015:0265 Critical CentOS 7 firefox Security Update
(Johnny Hughes)
--
Message: 1
Date: Wed, 25 Feb 2015 03:04:39 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2015:0265 Critical CentOS 6 firefox
SecurityUpdate
Message-ID: <20150225030439.ga60...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2015:0265 Critical
Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0265.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
d4fed3ff8afebc14157cba680c25210046a88a743894ddb427031248f1591f83
firefox-31.5.0-1.el6.centos.i686.rpm
x86_64:
d4fed3ff8afebc14157cba680c25210046a88a743894ddb427031248f1591f83
firefox-31.5.0-1.el6.centos.i686.rpm
d03d426c5fe418c3a6032ccf194633f62c29c2fc17c07de1a5eadbf4c1cab7e5
firefox-31.5.0-1.el6.centos.x86_64.rpm
Source:
82d2c4373bc2deaa94c354e5faee6ae55e49120959a222cd22058403aa7d8047
firefox-31.5.0-1.el6.centos.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
--
Message: 2
Date: Wed, 25 Feb 2015 03:15:42 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2015:0265 Critical CentOS 5 firefox
SecurityUpdate
Message-ID: <20150225031542.ga18...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2015:0265 Critical
Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0265.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
4cf9384a3b5d642c92a58cd8d0b665d686211f32077bd2619efa802d74f4dacf
firefox-31.5.0-1.el5.centos.i386.rpm
x86_64:
4cf9384a3b5d642c92a58cd8d0b665d686211f32077bd2619efa802d74f4dacf
firefox-31.5.0-1.el5.centos.i386.rpm
1d1a00f3f3d810d2580006b271de8c359c14f9012e7168a55805a64b540114ea
firefox-31.5.0-1.el5.centos.x86_64.rpm
Source:
59f429916e642c061a7577c23570e56e5b61e9a6fd91b7f31751b7049fde6d68
firefox-31.5.0-1.el5.centos.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
--
Message: 3
Date: Wed, 25 Feb 2015 03:27:11 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2015:0265 Critical CentOS 7 firefox
SecurityUpdate
Message-ID: <20150225032711.ga13...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2015:0265 Critical
Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0265.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
bb5ccc0f99270fe4513cf433de7780f18e00d24a2c544050c4b7bb45cd1e40b0
firefox-31.5.0-2.el7.centos.i686.rpm
59ef15c77888ba36e166177960ae34ccd135d22157d9306f3ef31722e8dd3afc
firefox-31.5.0-2.el7.centos.x86_64.rpm
97efe63b7aab8bcbbdf17cba51aea4a68662755181b79feff8bb9fa0a845f348
xulrunner-31.5.0-1.el7.centos.i686.rpm
b232b11d86bcd3017c1becbb0727f5a84bea5b95a30a58e29b289a64e069022f
xulrunner-31.5.0-1.el7.centos.x86_64.rpm
b79179ace2c967097f99a7f14cb4ee68af720248521cc10afd9ceae277f406f9
xulrunner-devel-31.5.0-1.el7.centos.i686.rpm
8721c0fad03ab5ef877200787bea9ba354ac97bba1474bd2db65bf6858bf4f4b
xulrunner-devel-31.5.0-1.el7.centos.x86_64.rpm
Source:
02135f20d1e24d14b2b587de7242900d57a504133eca7d97bdae81e52db1a87d
firefox-31.5.0-2.el7.centos.src.rpm
5df824f2eed96f62e869beb42ca1cd4486a5936cede043598c1bf762ff76d939
xulrunner-31.5.0-1.el7.centos.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
--
___
CentOS-announce mailing list
centos-annou...@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
End of CentOS-announce Digest, Vol 120, Issue 9
***
___
CentOS mailing list
Ce
[CentOS] Disable DHCPv6 on Cent7
So, I'm seeing a bunch of DHCPv6 traffic coming from my CentOS7 machines. Basically, the machines are trying to send router solicitations, the packets are blocked at their egress firewalls, and I get to see the logs. I don't wish to disable IPv6. I don't wish to statically configure IPv6 at this time. I wish to have the machines no longer attempting to send router solicitations as part of DHCPv6. How do I do this? I tried DHCPV6C="no" in ifcfg-ifacethatsnoteth0, but that seems to have had no effect. I still see lines like these: Feb 25 10:25:48 proxy-comcast-2 NetworkManager[541]: [1424877948.384918] [rdisc/nm-lndp-rdisc.c:241] send_rs(): ([snip]): cannot send router solicitation: -1. Feb 25 10:25:48 proxy-comcast-2 kernel: OUT-world:IN= OUT=[snip] SRC=fe80:[snip] DST=ff02:::::::0002 LEN=48 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0 -- :wq ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] unable to umount
Am 22.02.2015 um 16:12 schrieb Stephen Harris : >> nothing is using the partition >> $ lsof |grep srv >> > > Although the prompt is a $, I assume you're actually doing this as root? Yeah - its a bad behaviour doing tasks with a # prompt and then making a request in mailinglists with $ as prompt. Sorry for that. >> $ umount /srv >> umount: /srv: device is busy >> umount: /srv: device is busy >> >> >> what could keeping the device "busy" ... ? > > Is the device NFS exported? I've seem that prevent umounting even though > nothing shows up in the process list. Its a local "virtual" device (raid controller exports it as one device). -- LF ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Wiki links broken
On 02/24/2015 09:35 AM, lheck...@users.sourceforge.net wrote: > >> I will change the instructions on the wiki to say to edit the files >> that are included in the centos-release rpm. > > Thanks, Johnny. > > That's not really my problem. My problem is that I now need to track an > additional channel for updates, with associated local mirror and scripting. > I was only vaguely aware of it until I was looking for an update I know I > saw in the announce digest and it wasn't in updates. Well, fasTrack is a Red Hat thing ... we just offer it as well, since they release the Source for it: http://www.redhat.com/rhn/rhndetails/fastrack/ signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] unable to umount
Am 22.02.2015 um 15:51 schrieb J Martin Rushton : >> on an EL5 XEN DOM0 system I have following volume >> >> $ df -h /srv FilesystemSize Used Avail Use% Mounted >> on /dev/sdc1 917G 858G 60G 94% /srv >> >> that partition was used by virtual machines but they were all >> halted. >> >> service xendomains stop >> >> $ xm list Name ID Mem(MiB) >> VCPUs State Time(s) Domain-0 0 >> 3000 2 r-695.1 >> >> $ service xend stop >> >> >> nothing is using the partition $ lsof |grep srv > > Run as root: > # lsof +D /srv okay - i will try this scan before booting next time. >> $ fuser -m /srv >> > > Again, run this as root. Compare (test example from my system): > $ fuser -m /boot 2>/dev/null | wc > 0 44 264 > # fuser -m /boot 2>/dev/null | wc > 0 2231338 > > That's 180 processes I'd miss as an ordinary user. yep - all my commands were executed as root user (sorry for the $ vs. # confusion) >> $ fuser -km /srv >> >> >> but i can not umount /srv >> >> $ umount /srv umount: /srv: device is busy umount: /srv: device is >> busy >> > > I'm sure you've checked, but where is your PWD? I am also not sitting on the device :-) -- Thanks LF ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disable DHCPv6 on Cent7
On Wed, Feb 25, 2015 at 10:27 AM, Michael Mol wrote: > So, I'm seeing a bunch of DHCPv6 traffic coming from my CentOS7 > machines. Basically, the machines are trying to send router > solicitations, the packets are blocked at their egress firewalls, and > I get to see the logs. > > I don't wish to disable IPv6. I don't wish to statically configure > IPv6 at this time. I wish to have the machines no longer attempting to > send router solicitations as part of DHCPv6. > > How do I do this? I tried > > DHCPV6C="no" > > in ifcfg-ifacethatsnoteth0, but that seems to have had no effect. I > still see lines like these: > > Feb 25 10:25:48 proxy-comcast-2 NetworkManager[541]: > [1424877948.384918] [rdisc/nm-lndp-rdisc.c:241] send_rs(): ([snip]): > cannot send router solicitation: -1. > Feb 25 10:25:48 proxy-comcast-2 kernel: OUT-world:IN= OUT=[snip] > SRC=fe80:[snip] DST=ff02:::::::0002 LEN=48 > TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0 So, DHCPV6C="no" seems to be useless. What's needed is IPV6INIT="no". That doesn't disable IPv6 (to do that, you have to use sysctl), but it does tell NetworkManager to not try to configure it. Which is fine. -- :wq ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disable DHCPv6 on Cent7
On Wed, 25 Feb 2015, Michael Mol wrote: On Wed, Feb 25, 2015 at 10:27 AM, Michael Mol wrote: So, I'm seeing a bunch of DHCPv6 traffic coming from my CentOS7 machines. Basically, the machines are trying to send router solicitations, the packets are blocked at their egress firewalls, and I get to see the logs. I don't wish to disable IPv6. I don't wish to statically configure IPv6 at this time. I wish to have the machines no longer attempting to send router solicitations as part of DHCPv6. How do I do this? I tried DHCPV6C="no" in ifcfg-ifacethatsnoteth0, but that seems to have had no effect. I still see lines like these: Feb 25 10:25:48 proxy-comcast-2 NetworkManager[541]: [1424877948.384918] [rdisc/nm-lndp-rdisc.c:241] send_rs(): ([snip]): cannot send router solicitation: -1. Feb 25 10:25:48 proxy-comcast-2 kernel: OUT-world:IN= OUT=[snip] SRC=fe80:[snip] DST=ff02:::::::0002 LEN=48 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=133 CODE=0 So, DHCPV6C="no" seems to be useless. What's needed is IPV6INIT="no". That doesn't disable IPv6 (to do that, you have to use sysctl), but it does tell NetworkManager to not try to configure it. Which is fine. Look at net.ipv6.conf.default.autoconf in sysctl; you can turn off autoconf by adjusting it. BTW: Autoconf router solicitations are different from DHCPv6 requests. This SANS blog post provides a very short introduction to them both: https://isc.sans.edu/diary/The+Good,+Bad+and+Ugly+about+Assigning+IPv6+Addresses/13978 -- Paul Heinlein heinl...@madboa.com 45°38' N, 122°6' W___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Replacement for NIS/NFS?
Le 24/02/2015 08:41, Andrew Holway a écrit : +1 for freeipa. It is an extremely well integrated domain controller with a functionality similar to Microsoft Active Directory. I want to thank everybody for their numerous and detailed answer posts to this thread. Looks like FreeIPA is the way to go. I guess I'll check it out in the weeks and months to come. Cheers, Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Easy way to strip down CentOS?
Hi, I wonder if there's an easy way to strip down an installation to the bare minimum, e. g. the packages you get when you select "minimum installation". In Slackware, the bone-headed package manager slackpkg has a few nice options, among which 'slackpkg clean-system', which removes all third-party packages in one single operation, or 'slackpkg remove ', which does exactly that. I know CentOS has yum groupinstall/groupremove etc. but as far as I can tell, if I only have a handful of packages from a package group installed, yum grouplist lists the group as not installed, so there's not an easy way to tell. You may wonder why I want to do this. I have CentOS installed on some sandbox machines here, and I like to fiddle with different desktops and setups just for the sake of experimenting. Cheers, Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Easy way to strip down CentOS?
On 2/25/2015 10:23 AM, Niki Kovacs wrote: I wonder if there's an easy way to strip down an installation to the bare minimum, e. g. the packages you get when you select "minimum installation". I install from the 'minimum' ISO, and get that off the bat, then just install the packages I need with yum -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Easy way to strip down CentOS?
Le 25/02/2015 19:36, John R Pierce a écrit : I install from the 'minimum' ISO, and get that off the bat, then just install the packages I need with yum I do the same, but my question is: how to do that the other way around? Let's say you start from the base system, then install a couple dozen command-line utilities from cowsay to whois, then you install the "X Window System" group, a couple dozen fonts, then the WindowMaker window manager, then a handful of X applications... how do you manage from there to get back to exactly the base system you had from the start? I know this may sound a little academic, but it's for a little private experiment here. Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Easy way to strip down CentOS?
On Wed, Feb 25, 2015 at 2:04 PM, Niki Kovacs wrote: > > Le 25/02/2015 19:36, John R Pierce a écrit : > >> I install from the 'minimum' ISO, and get that off the bat, then just >> install the packages I need with yum >> > > I do the same, but my question is: how to do that the other way around? > Let's say you start from the base system, then install a couple dozen > command-line utilities from cowsay to whois, then you install the "X Window > System" group, a couple dozen fonts, then the WindowMaker window manager, > then a handful of X applications... how do you manage from there to get > back to exactly the base system you had from the start? I know this may > sound a little academic, but it's for a little private experiment here. > > Niki > It's not automatic so maybe not what you're looking for, but reviewing the yum log in /var/log/ will give you a chronological list of what packages were installed, so you could use that create a list of packages to remove. Be careful about updates that masquerade as installations, like kernel packages. You could also query by install date as outlined here: http://unix.stackexchange.com/questions/2291/centos-list-the-installed-rpms-by-date-of-installation-update I don't think there's a single yum command that lets you roll back to the packages the were installed at a given point in time. I also don't think that this would get you back to the *exact* system as it was. Linux packages aren't completely self contained like that, and have the potential to make other changes to the system, so it's not a completely clean rollback. At minimum, you'd have rpmsave files laying around, probably empty directories, etc... ❧ Brian Mathis @orev ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Easy way to strip down CentOS?
On Wed, 25 Feb 2015 20:04:22 +0100
Niki Kovacs wrote:
> how do you manage from
> there to get back to exactly the base system you had from the start?
My approach would be to create a list of installed rpms for what you're using
as the base system:
rpm -qa --qf "%{NAME}\n" | sort > starting.txt
Run that command again when you have all of the extra stuff installed, using a
different filename for the output, for example, ending.txt
Now merge and compare those files, and pull out the unique entries:
sort starting.txt ending.txt | uniq -u > newstuff.txt
Now remove the files in newstuff.txt
yum remove `cat newstuff.txt`
There is probably a way to combine those last two steps into one single command.
--
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
Ok, so some of this now works, but I'm still having problems. With the bootif option, the system now correctly configures and uses the same interface to get its kickstart file. However, when the system is done and boots up, the interfaces are still messed up. So this is what I have in the kickstart file: # On-Board Port 1 with public IP configuration network --noipv6 --onboot yes --bootproto static --device eth0 --ip x.x.x.x --netmask y.y.y.y --gateway z.z.z.z # On-Board Port 2 on private subnet A network --noipv6 --onboot yes --bootproto dhcp --hostname portico # Ethernet Card on private subnet B network --noipv6 --onboot yes --bootproto dhcp --device eth2 In the PXE config file I have: IPAPPEND 2 APPEND ks=http://192.168.x.x/ks/portico.ks initrd=centos/x86_64/initrd.img ramdisk_size=10 ksdevice=bootif When the system comes up and PXE kicks in, it will get an IP on its second port (eth1) to the 192.168.x.x subnet where the kickstart and install files are. When the system is completely done and boots back up, it should have: port 1 (eth0) with the static public IP assigned from the ks file port 2 (eth1) with the same DHCP assigned ip that the PXE originally received And eth2, which is an additional ethernet card will get another IP from a different dhcp server on a separate subnet. What's happening now is, PXE gets an IP, the system will successfully get the kickstart file and go through the full setup process, however when it reboots, this is what I end up with as far as the ethernet ports: The additional ethernet card is configured as eth0, with the public IP that the kickstart file has in it port 1 (now eth1 instead of eth0) is configured with a 10.1.10.10 IP ... Whiskey Tango Foxtrot?? port 2 (now eth2 instead of eth1) is configured with the dhcp IP that it was given during the setup. This results in nothing working as the ports are wired into specific routers and if the boot process renames/reshuffles them, I'm left with a machine I can not get on to and that doesn't work on the network. As soon as I *remove* the additional ethernet card, the system will boot up with the ports configured correctly (port 1 = eth0, port 2 = eth1). So why is it that as soon as there is an additional one, all things go to hell? Why must the boot process shuffle them? More importantly, how do I prevent this so that the system comes up properly after a kickstart install? On Tue, Feb 24, 2015 at 6:47 PM, Digimer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 23/02/15 08:16 PM, Steven Tardy wrote: > > > >> On Feb 23, 2015, at 6:34 PM, Ashley M. Kirchner > >> wrote: > >> > >> I have a Dell server that has two built-in ethernet devices. When > >> I kickstart the machine, they are correctly identified as eth0 > >> and eth1 (correctly meaning they correspond to the physical > >> device ports 1 and 2). I need a third one and want that to come > >> up as eth2. After adding the hardware, kickstart now fails > >> because for some reason it goes through a rename process where it > >> makes the newly added card eth1 (or eth0, I forgot). Is there a > >> way to stop this rename process so kickstart correctly uses the > >> physical hardware the way they are, meaning physical port 1 = > >> eth0, port 2 = eth1, and the additional ethernet card then > >> becomes eth2? > >> > >> Should I be using the device's MAC address when I set the > >> 'network' option in the kickstart file? So instead of 'network > >> --device=eth0' I make it 'network -device=aa;bb:cc:dd:eee:ff' ? > >> > > > > kickstart has an option: ksdevice=bootif > > > > I think that'll let you accomplish what you are trying. > > Totally unrelated, but this is the reason I love discussions like this > getting into the archives. I had no idea this option existed and it > just solved an annoying problems I've been trying to think how to > solve for ages! > > In PXE's 'default'; > > LABEL new-node1 > MENU LABEL ^1) New Node 1 - RHEL 6 > KERNEL boot/rhel6/x86_64/vmlinuz > IPAPPEND 2 > APPEND initrd=boot/rhel6/x86_64/initrd.img > ks=http://10.20.4.1/rhel6/x86_64/ks/pxe-ccrs-node2.ks ksdevice=bootif > > Then in kickstart; > > network --bootproto dhcp --onboot yes --hostname node1.example.com > > (not the lack of --device) > > With this, my nodes with 6 NICs reliably boot without asking the user > to choose the NIC by MAC they want to install from. > > Thanks!! > > - -- > Digimer > Papers and Projects: https://alteeve.ca/w/ > What if the cure for cancer is trapped in the mind of a person without > access to education? > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJU7SnDAAoJECChztQA3mh0+dEQAMWM705Tc9fWr/ODiLDQNQHk > 5todiurUcM72zPn3NCwiLTb/ZEXbnkL74Zy7qQPf8zzFryLIuldGMDIVIgVp5k3m > LnkU9dW0zguXnCfde3gXJs8taYSAYA/ciwO9mE+M3V4+VU6TvzjPkVxKGkhTxjTL > 5/DBz1N9V6IChRLbjcQbkHJD5gAPY0cloOoP6f0FC/k+Ojeo7oUibYQjVB8nDkwa > cfxxJ2yYIjOkTBm7vQuLnHf64jR8siqN9Zw5gZuuTBfbK2gIuMw99Fg7/QAEe85h > uQttjHloI1SfhYN4D5AuQzeX
Re: [CentOS] Kickstart with multiple eth devices
On 02/25/2015 01:56 PM, Ashley M. Kirchner wrote: > Ok, so some of this now works, but I'm still having problems. With the > bootif option, the system now correctly configures and uses the same > interface to get its kickstart file. However, when the system is done and > boots up, the interfaces are still messed up. So this is what I have in the > kickstart file: What version of CentOS 6 is this? > In the PXE config file I have: > > IPAPPEND 2 > APPEND ks=http://192.168.x.x/ks/portico.ks initrd=centos/x86_64/initrd.img > ramdisk_size=10 ksdevice=bootif > As soon as I *remove* the additional ethernet card, the system will boot up > with the ports configured correctly (port 1 = eth0, port 2 = eth1). So why > is it that as soon as there is an additional one, all things go to hell? > Why must the boot process shuffle them? More importantly, how do I prevent > this so that the system comes up properly after a kickstart install? > The reason I ask the version, is this is exactly the sort of thing that biosdevname is designed to solve. With biosdevname, you get devices like 'em1, em2, p6p1', which aren't as friendly as 'eth0' but also keep names sane and avoid the hair-tearing issues you're experiencing currently. You don't appear to be adding anything via your append line that would disable biosdevname, so I must assume you're using a much older 6 base install. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
Version 6.6 ... On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin wrote: > > > On 02/25/2015 01:56 PM, Ashley M. Kirchner wrote: > > Ok, so some of this now works, but I'm still having problems. With the > > bootif option, the system now correctly configures and uses the same > > interface to get its kickstart file. However, when the system is done and > > boots up, the interfaces are still messed up. So this is what I have in > the > > kickstart file: > > What version of CentOS 6 is this? > > > In the PXE config file I have: > > > > IPAPPEND 2 > > APPEND ks=http://192.168.x.x/ks/portico.ks > initrd=centos/x86_64/initrd.img > > ramdisk_size=10 ksdevice=bootif > > > As soon as I *remove* the additional ethernet card, the system will boot > up > > with the ports configured correctly (port 1 = eth0, port 2 = eth1). So > why > > is it that as soon as there is an additional one, all things go to hell? > > Why must the boot process shuffle them? More importantly, how do I > prevent > > this so that the system comes up properly after a kickstart install? > > > > The reason I ask the version, is this is exactly the sort of thing that > biosdevname is designed to solve. With biosdevname, you get devices like > 'em1, em2, p6p1', which aren't as friendly as 'eth0' but also keep names > sane and avoid the hair-tearing issues you're experiencing currently. > You don't appear to be adding anything via your append line that would > disable biosdevname, so I must assume you're using a much older 6 base > install. > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > ___ > 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] Kickstart with multiple eth devices
Starting back in RHEL/Cent 5 I found that the only way to make sure your interface enumeration was consistent after install with what you had during install was to create a udev rules file using the mac addresses as the key. It is easy to run a short script in postinstall to create it based on how anaconda has seen them. In order for this to work on Cent 6 you have to set biosdevname=0 on the kernel boot for the installed system. PXE boot options: label c6inst-sda kernel /linux-boot/cent6-x64/vmlinuz append initrd=/linux-boot/cent6-x64/initrd.img ksdevice=bootif ip=dhcp ks=http://xx.xx.xx.xx/install/linux/ks/basic-cent6-sda.cfg ipappend 2 In kickstart: BOOTOPTS="biosdevname=0" Also in kickstart I do not specify the config for ANY network interfaces. I let anaconda pull in only the config for the boot interface from PXE. I manually configure everything else. The only thing I do to non-boot interfaces is set the DHCP and ONBOOT to no. On Wed, 25 Feb 2015 14:21:18 -0600, Ashley M. Kirchner wrote: Version 6.6 ... On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin wrote: On 02/25/2015 01:56 PM, Ashley M. Kirchner wrote: > Ok, so some of this now works, but I'm still having problems. With the > bootif option, the system now correctly configures and uses the same > interface to get its kickstart file. However, when the system is done and > boots up, the interfaces are still messed up. So this is what I have in the > kickstart file: What version of CentOS 6 is this? > In the PXE config file I have: > > IPAPPEND 2 > APPEND ks=http://192.168.x.x/ks/portico.ks initrd=centos/x86_64/initrd.img > ramdisk_size=10 ksdevice=bootif > As soon as I *remove* the additional ethernet card, the system will boot up > with the ports configured correctly (port 1 = eth0, port 2 = eth1). So why > is it that as soon as there is an additional one, all things go to hell? > Why must the boot process shuffle them? More importantly, how do I prevent > this so that the system comes up properly after a kickstart install? > The reason I ask the version, is this is exactly the sort of thing that biosdevname is designed to solve. With biosdevname, you get devices like 'em1, em2, p6p1', which aren't as friendly as 'eth0' but also keep names sane and avoid the hair-tearing issues you're experiencing currently. You don't appear to be adding anything via your append line that would disable biosdevname, so I must assume you're using a much older 6 base install. In my experience biosdevname creates just as many problems as it solves. Dell can keep it. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ___ 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 mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 7, systemd and firewall-cmd
I'm having issues with an rsyncd. systemctl status rsyncd shows it running rsyncd.service - fast remote file copy program daemon Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; enabled) Active: active (running) since Wed 2015-02-25 10:57:02 EST; 4h 43min ago Main PID: 31672 (rsync) CGroup: /system.slice/rsyncd.service `-31672 /usr/bin/rsync --daemon --no-detach But firewall-cmd --list-all public (default, active) interfaces: em1 em2 sources: services: dhcpv6-client mountd nfs rpc-bind samba ssh ports: 631/udp 22/tcp masquerade: no forward-ports: icmp-blocks: rich rules: And yet if I do iptables-save, it shows 873 open. a) which should I believe, firewall-cmd or iptables-save? b) why does firewall-cmd not show 837 open? c) I've been googling, and know that I can tell firewall-cmd to open the port, but if there's a "correct" way, presumably one that will show rsyncd on the services line, I'd like to do it that way. Clues? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Easy way to strip down CentOS?
On 2/25/2015 12:04 PM, Niki Kovacs wrote: Le 25/02/2015 19:36, John R Pierce a écrit : I install from the 'minimum' ISO, and get that off the bat, then just install the packages I need with yum I do the same, but my question is: how to do that the other way around? Let's say you start from the base system, then install a couple dozen command-line utilities from cowsay to whois, then you install the "X Window System" group, a couple dozen fonts, then the WindowMaker window manager, then a handful of X applications... how do you manage from there to get back to exactly the base system you had from the start? I know this may sound a little academic, but it's for a little private experiment here. Before I discovered the minimal iso I found that I could unselect everything and still get a working install with CentOS on my servers. Curiously, that didn't work with RedHat, had to at least select the "base" option and then go thru the base options to deselect bits. My experience is only up thru v6, don't know about v7 (refuse to use it for now). -- Steve ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Easy way to strip down CentOS?
Le 25/02/2015 20:18, Brian Mathis a écrit : I don't think there's a single yum command that lets you roll back to the packages the were installed at a given point in time. Maybe a good idea would be to find one or a handful of packages that the whole desktop and/or graphical subsystem depends on. Removing this one package - or this handful of packages, but which? - would already result in removing everything X11-related. After that, I can always manually sort out the remaining command-line stuff. Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
Thanks for that Jason but it didn't solve the problem. The system is still coming up with the interfaces shuffled. It seems to *always* want to use the added ethernet card as eth0. On Wed, Feb 25, 2015 at 1:37 PM, Jason Warr wrote: > Starting back in RHEL/Cent 5 I found that the only way to make sure your > interface enumeration was consistent after install with what you had during > install was to create a udev rules file using the mac addresses as the > key. It is easy to run a short script in postinstall to create it based on > how anaconda has seen them. > > In order for this to work on Cent 6 you have to set biosdevname=0 on the > kernel boot for the installed system. > > PXE boot options: > > label c6inst-sda > kernel /linux-boot/cent6-x64/vmlinuz > append initrd=/linux-boot/cent6-x64/initrd.img ksdevice=bootif > ip=dhcp ks=http://xx.xx.xx.xx/install/linux/ks/basic-cent6-sda.cfg > ipappend 2 > > In kickstart: > > BOOTOPTS="biosdevname=0" > > Also in kickstart I do not specify the config for ANY network interfaces. > I let anaconda pull in only the config for the boot interface from PXE. I > manually configure everything else. The only thing I do to non-boot > interfaces is set the DHCP and ONBOOT to no. > > > > On Wed, 25 Feb 2015 14:21:18 -0600, Ashley M. Kirchner > wrote: > > Version 6.6 ... >> >> On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin wrote: >> >> >>> >>> On 02/25/2015 01:56 PM, Ashley M. Kirchner wrote: >>> > Ok, so some of this now works, but I'm still having problems. With the >>> > bootif option, the system now correctly configures and uses the same >>> > interface to get its kickstart file. However, when the system is done >>> and >>> > boots up, the interfaces are still messed up. So this is what I have in >>> the >>> > kickstart file: >>> >>> What version of CentOS 6 is this? >>> >>> > In the PXE config file I have: >>> > >>> > IPAPPEND 2 >>> > APPEND ks=http://192.168.x.x/ks/portico.ks >>> initrd=centos/x86_64/initrd.img >>> > ramdisk_size=10 ksdevice=bootif >>> >>> > As soon as I *remove* the additional ethernet card, the system will >>> boot >>> up >>> > with the ports configured correctly (port 1 = eth0, port 2 = eth1). So >>> why >>> > is it that as soon as there is an additional one, all things go to >>> hell? >>> > Why must the boot process shuffle them? More importantly, how do I >>> prevent >>> > this so that the system comes up properly after a kickstart install? >>> > >>> >>> The reason I ask the version, is this is exactly the sort of thing that >>> biosdevname is designed to solve. With biosdevname, you get devices like >>> 'em1, em2, p6p1', which aren't as friendly as 'eth0' but also keep names >>> sane and avoid the hair-tearing issues you're experiencing currently. >>> You don't appear to be adding anything via your append line that would >>> disable biosdevname, so I must assume you're using a much older 6 base >>> install. >>> >>> > In my experience biosdevname creates just as many problems as it solves. > Dell can keep it. > > > >>> -- >>> Jim Perrin >>> The CentOS Project | http://www.centos.org >>> twitter: @BitIntegrity | GPG Key: FA09AD77 >>> ___ >>> 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 mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
Here is my script for post install if you want to try it.
In order for the shuffling to not occur you do need to create the udev
rules file somehow. I am not sure how mangled this will be in email but
it is worth a try. It should run OK with nothing else. I have a better
version in the works but the enhancements are mainly useful for Fedora
19-21.
I did forget to say I also block NetworkManager from the interfaces.
#!/bin/bash
## BIND MAC address to proper interfaces so they stay persistent
## I want them to stay as they were in kickstart
## This can cause issues with VLAN interfaces for both bond dev's and base
eth dev's.
## The bond one was solved by adding in the "KERNEL="eth?*" as that will
only apply to physical
## Devices. Once we have VLAN's on a real device instead of just on
BOND's this then applies
## to the hardware devices as well. The core issue is that the MAC
address is inherited
## by all of the children devices and thus the UDEV rule has to be
crafted to only apply
## to the base physical device.
## This one was solved via adding DRIVERS=="?*" as the VLAN int's wont
have one
echo "[KICKSTART] Binding eth interfaces to the expected MAC address
in UDEV"
echo "## Created by Kickstart to keep network interfaces in an
expected order" > \
/etc/udev/rules.d/70-persistent-net.rules
echo "" >> \
/etc/udev/rules.d/70-persistent-net.rules
cd /sys/class/net/
for NETDEV in $(ls | grep eth | sort)
do
## Create a UDEV rule for each eth interface
echo "## ${NETDEV} interface" >> \
/etc/udev/rules.d/70-persistent-net.rules
## We throw this one in here as it can contain some useful
information
echo "## $(dmesg | grep ${NETDEV} | grep -i -v -e "console" -e
"Command line" | head -1)" >> \
/etc/udev/rules.d/70-persistent-net.rules
echo -n "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", "
\
/etc/udev/rules.d/70-persistent-net.rules
echo -n "ATTR{address}==\"$(cat ${NETDEV}/address)\", " >> \
/etc/udev/rules.d/70-persistent-net.rules
echo -n "ATTR{dev_id}==\"0x0\", ATTR{type}==\"1\",
KERNEL==\"eth?*\", " >> \
/etc/udev/rules.d/70-persistent-net.rules
echo -e "NAME=\"${NETDEV}\"\n" >> \
/etc/udev/rules.d/70-persistent-net.rules
## Make a log of the devices present during install
echo -e "${NETDEV} $(cat ${NETDEV}/address)\n" >>
/root/ksnet-devices
## Also remove the HWADDR line from all of the net config files
grep -v -e NAME -e HWADDR -e NM_CONTROLLED \
/etc/sysconfig/network-scripts/ifcfg-${NETDEV} | sed 's/\"//g'
\
> /etc/sysconfig/network-scripts/ifcfg-${NETDEV}-tmp
echo "NM_CONTROLLED=no" >>
/etc/sysconfig/network-scripts/ifcfg-${NETDEV}-tmp
/usr/bin/perl -p -i -e 's/dhcp/none/'
/etc/sysconfig/network-scripts/ifcfg-${NETDEV}-tmp
mv -f /etc/sysconfig/network-scripts/ifcfg-${NETDEV}-tmp \
/etc/sysconfig/network-scripts/ifcfg-${NETDEV}
done
###
On Wed, 25 Feb 2015 14:53:40 -0600, Ashley M. Kirchner
wrote:
Thanks for that Jason but it didn't solve the problem. The system is
still
coming up with the interfaces shuffled. It seems to *always* want to use
the added ethernet card as eth0.
On Wed, Feb 25, 2015 at 1:37 PM, Jason Warr wrote:
Starting back in RHEL/Cent 5 I found that the only way to make sure your
interface enumeration was consistent after install with what you had
during
install was to create a udev rules file using the mac addresses as the
key. It is easy to run a short script in postinstall to create it
based on
how anaconda has seen them.
In order for this to work on Cent 6 you have to set biosdevname=0 on the
kernel boot for the installed system.
PXE boot options:
label c6inst-sda
kernel /linux-boot/cent6-x64/vmlinuz
append initrd=/linux-boot/cent6-x64/initrd.img ksdevice=bootif
ip=dhcp ks=http://xx.xx.xx.xx/install/linux/ks/basic-cent6-sda.cfg
ipappend 2
In kickstart:
BOOTOPTS="biosdevname=0"
Also in kickstart I do not specify the config for ANY network
interfaces.
I let anaconda pull in only the config for the boot interface from
PXE. I
manually configure everything else. The only thing I do to non-boot
interfaces is set the DHCP and ONBOOT to no.
On Wed, 25 Feb 2015 14:21:18 -0600, Ashley M. Kirchner
wrote:
Version 6.6 ...
On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin wrote:
On 02/25/2015 01:56 PM, Ashley M. Kirchner wrote:
> Ok, so some of this now works, but I'm still having problems. With
the
> bootif option, the system now correctly configures and uses the same
> interface to get its kickstart file. However, when the system is
done
and
> boots up, the interfaces are still messed up. So this is what I
have in
the
> kickstart
Re: [CentOS] CentOS 7, systemd and firewall-cmd
firewall-cmd --add-service=rsyncd To make it permanent, do the above and this: firewall-cmd --permanent --add-service=rsyncd Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7, systemd and firewall-cmd
Chris Murphy wrote: > firewall-cmd --add-service=rsyncd > firewall-cmd --add-service=rsyncd Error: INVALID_SERVICE: rsyncd Is there another place that there needs to be an rsyncd service file, whatever it's supposed to be named, *other* than where systemd wants it? mark > To make it permanent, do the above and this: > firewall-cmd --permanent --add-service=rsyncd > > > Chris Murphy > ___ > 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] CentOS 7, systemd and firewall-cmd
On Wed, 2015-02-25 at 16:33 -0500, m.r...@5-cent.us wrote: > Chris Murphy wrote: > > firewall-cmd --add-service=rsyncd > > > firewall-cmd --add-service=rsyncd > Error: INVALID_SERVICE: rsyncd > > Is there another place that there needs to be an rsyncd service file, > whatever it's supposed to be named, *other* than where systemd wants it? > > mark > You can also specify the port firewall-cmd --permanent --add-port=/tcp > > To make it permanent, do the above and this: > > firewall-cmd --permanent --add-service=rsyncd > > > > > > Chris Murphy > > ___ > > 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 mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Easy way to strip down CentOS?
On 02/26/2015 07:23 AM, Niki Kovacs wrote: > I wonder if there's an easy way to strip down an installation to the > bare minimum, e. g. the packages you get when you select "minimum > installation". I haven't tried this, but see if it works: yum shell remove * install @minimal run Peter ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
Ok, when I run that, it creates a now "custom" 70-persistent-net.rules, but
the interfaces are still out of order, with the added one listed first, and
the built-ins 2nd and 3rd.
On Wed, Feb 25, 2015 at 2:00 PM, Jason Warr wrote:
> Here is my script for post install if you want to try it.
>
> In order for the shuffling to not occur you do need to create the udev
> rules file somehow. I am not sure how mangled this will be in email but it
> is worth a try. It should run OK with nothing else. I have a better
> version in the works but the enhancements are mainly useful for Fedora
> 19-21.
>
> I did forget to say I also block NetworkManager from the interfaces.
>
>
>
> #!/bin/bash
> ## BIND MAC address to proper interfaces so they stay persistent
> ## I want them to stay as they were in kickstart
>
> ## This can cause issues with VLAN interfaces for both bond dev's and base
> eth dev's.
> ## The bond one was solved by adding in the "KERNEL="eth?*" as that will
> only apply to physical
> ## Devices. Once we have VLAN's on a real device instead of just on
> BOND's this then applies
> ## to the hardware devices as well. The core issue is that the MAC
> address is inherited
> ## by all of the children devices and thus the UDEV rule has to be
> crafted to only apply
> ## to the base physical device.
> ## This one was solved via adding DRIVERS=="?*" as the VLAN int's wont
> have one
>
> echo "[KICKSTART] Binding eth interfaces to the expected MAC address
> in UDEV"
> echo "## Created by Kickstart to keep network interfaces in an
> expected order" > \
> /etc/udev/rules.d/70-persistent-net.rules
> echo "" >> \
> /etc/udev/rules.d/70-persistent-net.rules
>
> cd /sys/class/net/
> for NETDEV in $(ls | grep eth | sort)
> do
> ## Create a UDEV rule for each eth interface
> echo "## ${NETDEV} interface" >> \
> /etc/udev/rules.d/70-persistent-net.rules
>
> ## We throw this one in here as it can contain some useful
> information
> echo "## $(dmesg | grep ${NETDEV} | grep -i -v -e "console" -e
> "Command line" | head -1)" >> \
> /etc/udev/rules.d/70-persistent-net.rules
>
> echo -n "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", "
>
>> \
>>>
>> /etc/udev/rules.d/70-persistent-net.rules
> echo -n "ATTR{address}==\"$(cat ${NETDEV}/address)\", " >> \
> /etc/udev/rules.d/70-persistent-net.rules
> echo -n "ATTR{dev_id}==\"0x0\", ATTR{type}==\"1\",
> KERNEL==\"eth?*\", " >> \
> /etc/udev/rules.d/70-persistent-net.rules
> echo -e "NAME=\"${NETDEV}\"\n" >> \
> /etc/udev/rules.d/70-persistent-net.rules
>
> ## Make a log of the devices present during install
> echo -e "${NETDEV} $(cat ${NETDEV}/address)\n" >>
> /root/ksnet-devices
>
> ## Also remove the HWADDR line from all of the net config files
> grep -v -e NAME -e HWADDR -e NM_CONTROLLED \
> /etc/sysconfig/network-scripts/ifcfg-${NETDEV} | sed
> 's/\"//g' \
> > /etc/sysconfig/network-scripts/ifcfg-${NETDEV}-tmp
> echo "NM_CONTROLLED=no" >> /etc/sysconfig/network-
> scripts/ifcfg-${NETDEV}-tmp
> /usr/bin/perl -p -i -e 's/dhcp/none/' /etc/sysconfig/network-
> scripts/ifcfg-${NETDEV}-tmp
> mv -f /etc/sysconfig/network-scripts/ifcfg-${NETDEV}-tmp \
> /etc/sysconfig/network-scripts/ifcfg-${NETDEV}
> done
>
> ###
>
>
> On Wed, 25 Feb 2015 14:53:40 -0600, Ashley M. Kirchner
> wrote:
>
> Thanks for that Jason but it didn't solve the problem. The system is still
>> coming up with the interfaces shuffled. It seems to *always* want to use
>> the added ethernet card as eth0.
>>
>> On Wed, Feb 25, 2015 at 1:37 PM, Jason Warr wrote:
>>
>> Starting back in RHEL/Cent 5 I found that the only way to make sure your
>>> interface enumeration was consistent after install with what you had
>>> during
>>> install was to create a udev rules file using the mac addresses as the
>>> key. It is easy to run a short script in postinstall to create it based
>>> on
>>> how anaconda has seen them.
>>>
>>> In order for this to work on Cent 6 you have to set biosdevname=0 on the
>>> kernel boot for the installed system.
>>>
>>> PXE boot options:
>>>
>>> label c6inst-sda
>>> kernel /linux-boot/cent6-x64/vmlinuz
>>> append initrd=/linux-boot/cent6-x64/initrd.img ksdevice=bootif
>>> ip=dhcp ks=http://xx.xx.xx.xx/install/linux/ks/basic-cent6-sda.cfg
>>> ipappend 2
>>>
>>> In kickstart:
>>>
>>> BOOTOPTS="biosdevname=0"
>>>
>>> Also in kickstart I do not specify the config for ANY network interfaces.
>>> I let anaconda pull in only the config for the boot interface from PXE.
>>> I
>>> manually configure everything else. The only thing I do to non-boot
>>> interfaces is set the DHCP and ONBOOT to no.
>>>
>>>
>>>
>>> On Wed, 25 Feb 2015 14:21:18 -0600, Ashley M. Ki
Re: [CentOS] Kickstart with multiple eth devices
Define out of order in this case just so I know for sure what you mean.
What my solution does, or at least does reliably in my case, is make sure
the interfaces are in the same order once installed as the install kernel
saw them. It won't re-order them to be sequential based on bus, mac or
driver. I am working on that but it will also include naming the devices
based on the module name, similar to how FreeBSD and Solaris do it.
Just to get an idea of what might be going on can you run "dmesg | grep
eth" so I can see some of what udev is doing?
On Wed, 25 Feb 2015 16:28:31 -0600, Ashley M. Kirchner
wrote:
Ok, when I run that, it creates a now "custom" 70-persistent-net.rules,
but
the interfaces are still out of order, with the added one listed first,
and
the built-ins 2nd and 3rd.
On Wed, Feb 25, 2015 at 2:00 PM, Jason Warr wrote:
Here is my script for post install if you want to try it.
In order for the shuffling to not occur you do need to create the udev
rules file somehow. I am not sure how mangled this will be in email
but it
is worth a try. It should run OK with nothing else. I have a better
version in the works but the enhancements are mainly useful for Fedora
19-21.
I did forget to say I also block NetworkManager from the interfaces.
#!/bin/bash
## BIND MAC address to proper interfaces so they stay persistent
## I want them to stay as they were in kickstart
## This can cause issues with VLAN interfaces for both bond dev's and
base
eth dev's.
## The bond one was solved by adding in the "KERNEL="eth?*" as that
will
only apply to physical
## Devices. Once we have VLAN's on a real device instead of just on
BOND's this then applies
## to the hardware devices as well. The core issue is that the MAC
address is inherited
## by all of the children devices and thus the UDEV rule has to be
crafted to only apply
## to the base physical device.
## This one was solved via adding DRIVERS=="?*" as the VLAN int's wont
have one
echo "[KICKSTART] Binding eth interfaces to the expected MAC address
in UDEV"
echo "## Created by Kickstart to keep network interfaces in an
expected order" > \
/etc/udev/rules.d/70-persistent-net.rules
echo "" >> \
/etc/udev/rules.d/70-persistent-net.rules
cd /sys/class/net/
for NETDEV in $(ls | grep eth | sort)
do
## Create a UDEV rule for each eth interface
echo "## ${NETDEV} interface" >> \
/etc/udev/rules.d/70-persistent-net.rules
## We throw this one in here as it can contain some useful
information
echo "## $(dmesg | grep ${NETDEV} | grep -i -v -e "console" -e
"Command line" | head -1)" >> \
/etc/udev/rules.d/70-persistent-net.rules
echo -n "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", "
\
/etc/udev/rules.d/70-persistent-net.rules
echo -n "ATTR{address}==\"$(cat ${NETDEV}/address)\", " >> \
/etc/udev/rules.d/70-persistent-net.rules
echo -n "ATTR{dev_id}==\"0x0\", ATTR{type}==\"1\",
KERNEL==\"eth?*\", " >> \
/etc/udev/rules.d/70-persistent-net.rules
echo -e "NAME=\"${NETDEV}\"\n" >> \
/etc/udev/rules.d/70-persistent-net.rules
## Make a log of the devices present during install
echo -e "${NETDEV} $(cat ${NETDEV}/address)\n" >>
/root/ksnet-devices
## Also remove the HWADDR line from all of the net config files
grep -v -e NAME -e HWADDR -e NM_CONTROLLED \
/etc/sysconfig/network-scripts/ifcfg-${NETDEV} | sed
's/\"//g' \
> /etc/sysconfig/network-scripts/ifcfg-${NETDEV}-tmp
echo "NM_CONTROLLED=no" >> /etc/sysconfig/network-
scripts/ifcfg-${NETDEV}-tmp
/usr/bin/perl -p -i -e 's/dhcp/none/' /etc/sysconfig/network-
scripts/ifcfg-${NETDEV}-tmp
mv -f /etc/sysconfig/network-scripts/ifcfg-${NETDEV}-tmp \
/etc/sysconfig/network-scripts/ifcfg-${NETDEV}
done
###
On Wed, 25 Feb 2015 14:53:40 -0600, Ashley M. Kirchner
wrote:
Thanks for that Jason but it didn't solve the problem. The system is
still
coming up with the interfaces shuffled. It seems to *always* want to
use
the added ethernet card as eth0.
On Wed, Feb 25, 2015 at 1:37 PM, Jason Warr wrote:
Starting back in RHEL/Cent 5 I found that the only way to make sure
your
interface enumeration was consistent after install with what you had
during
install was to create a udev rules file using the mac addresses as the
key. It is easy to run a short script in postinstall to create it
based
on
how anaconda has seen them.
In order for this to work on Cent 6 you have to set biosdevname=0 on
the
kernel boot for the installed system.
PXE boot options:
label c6inst-sda
kernel /linux-boot/cent6-x64/vmlinuz
append initrd=/linux-boot/cent6-x64/initrd.img ksdevice=bootif
ip=dhcp ks=http://xx.xx.xx.xx/install/linux/ks/basic-cent6-
Re: [CentOS] Kickstart with multiple eth devices
Out of order meaning, it puts the additional ethernet card as eth0, with
the built-in ports as eth1 and eth2 respectively. WITHOUT the additional
card installed, it puts the built-in ports as eth0 and eth1, which is what
I want it to do. The additional card should be eth2, at least that's what I
want it to do.
Looking at persistent-net.rules, it always puts the additional card first,
both without your script as well as with. I need it to be last. The
system's built-ins should always be eth0 and eth1 respectively.
And dmesg confirms it as well, it identifies the added card first (and
assigns it eth0), then identifies the built-in ports. I'd grab the actual
output except I need to manually reconfigure the interfaces so I can
actually get ON the machine. Right now I'm just looking at its console.
On Wed, Feb 25, 2015 at 3:37 PM, Jason Warr wrote:
> Define out of order in this case just so I know for sure what you mean.
>
> What my solution does, or at least does reliably in my case, is make sure
> the interfaces are in the same order once installed as the install kernel
> saw them. It won't re-order them to be sequential based on bus, mac or
> driver. I am working on that but it will also include naming the devices
> based on the module name, similar to how FreeBSD and Solaris do it.
>
> Just to get an idea of what might be going on can you run "dmesg | grep
> eth" so I can see some of what udev is doing?
>
>
>
> On Wed, 25 Feb 2015 16:28:31 -0600, Ashley M. Kirchner
> wrote:
>
> Ok, when I run that, it creates a now "custom" 70-persistent-net.rules,
>> but
>> the interfaces are still out of order, with the added one listed first,
>> and
>> the built-ins 2nd and 3rd.
>>
>> On Wed, Feb 25, 2015 at 2:00 PM, Jason Warr wrote:
>>
>> Here is my script for post install if you want to try it.
>>>
>>> In order for the shuffling to not occur you do need to create the udev
>>> rules file somehow. I am not sure how mangled this will be in email but
>>> it
>>> is worth a try. It should run OK with nothing else. I have a better
>>> version in the works but the enhancements are mainly useful for Fedora
>>> 19-21.
>>>
>>> I did forget to say I also block NetworkManager from the interfaces.
>>>
>>>
>>>
>>> #!/bin/bash
>>> ## BIND MAC address to proper interfaces so they stay persistent
>>> ## I want them to stay as they were in kickstart
>>>
>>> ## This can cause issues with VLAN interfaces for both bond dev's and
>>> base
>>> eth dev's.
>>> ## The bond one was solved by adding in the "KERNEL="eth?*" as that will
>>> only apply to physical
>>> ## Devices. Once we have VLAN's on a real device instead of just on
>>> BOND's this then applies
>>> ## to the hardware devices as well. The core issue is that the MAC
>>> address is inherited
>>> ## by all of the children devices and thus the UDEV rule has to be
>>> crafted to only apply
>>> ## to the base physical device.
>>> ## This one was solved via adding DRIVERS=="?*" as the VLAN int's wont
>>> have one
>>>
>>> echo "[KICKSTART] Binding eth interfaces to the expected MAC address
>>> in UDEV"
>>> echo "## Created by Kickstart to keep network interfaces in an
>>> expected order" > \
>>> /etc/udev/rules.d/70-persistent-net.rules
>>> echo "" >> \
>>> /etc/udev/rules.d/70-persistent-net.rules
>>>
>>> cd /sys/class/net/
>>> for NETDEV in $(ls | grep eth | sort)
>>> do
>>> ## Create a UDEV rule for each eth interface
>>> echo "## ${NETDEV} interface" >> \
>>> /etc/udev/rules.d/70-persistent-net.rules
>>>
>>> ## We throw this one in here as it can contain some useful
>>> information
>>> echo "## $(dmesg | grep ${NETDEV} | grep -i -v -e "console" -e
>>> "Command line" | head -1)" >> \
>>> /etc/udev/rules.d/70-persistent-net.rules
>>>
>>> echo -n "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", "
>>>
>>> \
>
> /etc/udev/rules.d/70-persistent-net.rules
>>> echo -n "ATTR{address}==\"$(cat ${NETDEV}/address)\", " >> \
>>> /etc/udev/rules.d/70-persistent-net.rules
>>> echo -n "ATTR{dev_id}==\"0x0\", ATTR{type}==\"1\",
>>> KERNEL==\"eth?*\", " >> \
>>> /etc/udev/rules.d/70-persistent-net.rules
>>> echo -e "NAME=\"${NETDEV}\"\n" >> \
>>> /etc/udev/rules.d/70-persistent-net.rules
>>>
>>> ## Make a log of the devices present during install
>>> echo -e "${NETDEV} $(cat ${NETDEV}/address)\n" >>
>>> /root/ksnet-devices
>>>
>>> ## Also remove the HWADDR line from all of the net config files
>>> grep -v -e NAME -e HWADDR -e NM_CONTROLLED \
>>> /etc/sysconfig/network-scripts/ifcfg-${NETDEV} | sed
>>> 's/\"//g' \
>>> > /etc/sysconfig/network-scripts/ifcfg-${NETDEV}-tmp
>>> echo "NM_CONTROLLED=no" >> /etc/sysconfig/network-
>>> scripts/ifcfg-${NETDEV}-tmp
>>> /usr/bin/perl -p -i -e 's
Re: [CentOS] Kickstart with multiple eth devices
Ashley M. Kirchner wrote: > Out of order meaning, it puts the additional ethernet card as eth0, with > the built-in ports as eth1 and eth2 respectively. WITHOUT the additional > card installed, it puts the built-in ports as eth0 and eth1, which is what > I want it to do. The additional card should be eth2, at least that's what > I want it to do. Now that you have a 70-persistant-net.rules, what happens if you edit it, and name the interfaces in the correct order, then reboot? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
On Wed, Feb 25, 2015 at 4:45 PM, Ashley M. Kirchner wrote: > Out of order meaning, it puts the additional ethernet card as eth0, with > the built-in ports as eth1 and eth2 respectively. WITHOUT the additional > card installed, it puts the built-in ports as eth0 and eth1, which is what > I want it to do. The additional card should be eth2, at least that's what I > want it to do. > > Looking at persistent-net.rules, it always puts the additional card first, > both without your script as well as with. I need it to be last. The > system's built-ins should always be eth0 and eth1 respectively. How can you confirm 'always' here? I haven't done it in the context of PXE booting, but I see random ordering of cards and motherboard nics on first installs with Centos6.x That is, the nics on the motherboard and on each card will have adjacent numbers but the cards and motherboard sets jump around until the MAC addresses are recorded in the etc/udev/rules.d/70-persistent-net.rules to nail them down. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
On Wed, 25 Feb 2015 16:45:04 -0600, Ashley M. Kirchner
wrote:
Out of order meaning, it puts the additional ethernet card as eth0, with
the built-in ports as eth1 and eth2 respectively. WITHOUT the additional
card >installed, it puts the built-in ports as eth0 and eth1, which is
what I want it to do. The additional card should be eth2, at least
that's what I want it to >do.
So if you really need them to be in that order your best bet may be to
blacklist the kernel module for the add in card so it does not get
enumerated during install. If you do that and create the udev rules file
as I do then on first boot udev should enforce your rules file and then
enumerate the add in card as eth2.
Add "rdblacklist=MODULE_NAME" to your append line in pxelinux.conf file.
This should get you into a usable state post-install so you can setup
additional interfaces.
Looking at persistent-net.rules, it always puts the additional card
first, both without your script as well as with. I need it to be last.
The system's built->ins should always be eth0 and eth1 respectively.
It looks like the add in card is in a bus slot that is getting enumerated,
module loaded before the on-board interfaces.
And dmesg confirms it as well, it identifies the added card first (and
assigns it eth0), then identifies the built-in ports. I'd grab the
actual output except >I need to manually reconfigure the interfaces so I
can actually get ON the machine. Right now I'm just looking at its
console
On Wed, Feb 25, 2015 at 3:37 PM, Jason Warr wrote:
Define out of order in this case just so I know for sure what you mean.
What my solution does, or at least does reliably in my case, is make
sure the interfaces are in the same order once installed as the install
kernel saw >>them. It won't re-order them to be sequential based on
bus, mac or driver. I am working on that but it will also include
naming the devices based on >>the module name, similar to how FreeBSD
and Solaris do it.
Just to get an idea of what might be going on can you run "dmesg | grep
eth" so I can see some of what udev is doing?
On Wed, 25 Feb 2015 16:28:31 -0600, Ashley M. Kirchner
wrote:
Ok, when I run that, it creates a now "custom"
70-persistent-net.rules, but
the interfaces are still out of order, with the added one listed
first, and
the built-ins 2nd and 3rd.
On Wed, Feb 25, 2015 at 2:00 PM, Jason Warr wrote:
Here is my script for post install if you want to try it.
In order for the shuffling to not occur you do need to create the udev
rules file somehow. I am not sure how mangled this will be in email
but it
is worth a try. It should run OK with nothing else. I have a better
version in the works but the enhancements are mainly useful for Fedora
19-21.
I did forget to say I also block NetworkManager from the interfaces.
#!/bin/bash
## BIND MAC address to proper interfaces so they stay persistent
## I want them to stay as they were in kickstart
## This can cause issues with VLAN interfaces for both bond dev's and
base
eth dev's.
## The bond one was solved by adding in the "KERNEL="eth?*" as that
will
only apply to physical
## Devices. Once we have VLAN's on a real device instead of just on
BOND's this then applies
## to the hardware devices as well. The core issue is that the MAC
address is inherited
## by all of the children devices and thus the UDEV rule has to be
crafted to only apply
## to the base physical device.
## This one was solved via adding DRIVERS=="?*" as the VLAN int's
wont
have one
echo "[KICKSTART] Binding eth interfaces to the expected MAC
address
in UDEV"
echo "## Created by Kickstart to keep network interfaces in an
expected order" > \
/etc/udev/rules.d/70-persistent-net.rules
echo "" >> \
/etc/udev/rules.d/70-persistent-net.rules
cd /sys/class/net/
for NETDEV in $(ls | grep eth | sort)
do
## Create a UDEV rule for each eth interface
echo "## ${NETDEV} interface" >> \
/etc/udev/rules.d/70-persistent-net.rules
## We throw this one in here as it can contain some useful
information
echo "## $(dmesg | grep ${NETDEV} | grep -i -v -e "console" -e
"Command line" | head -1)" >> \
/etc/udev/rules.d/70-persistent-net.rules
echo -n "SUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\",
"
\
/etc/udev/rules.d/70-persistent-net.rules
echo -n "ATTR{address}==\"$(cat ${NETDEV}/address)\", " >> \
/etc/udev/rules.d/70-persistent-net.rules
echo -n "ATTR{dev_id}==\"0x0\", ATTR{type}==\"1\",
KERNEL==\"eth?*\", " >> \
/etc/udev/rules.d/70-persistent-net.rules
echo -e "NAME=\"${NETDEV}\"\n" >> \
/etc/udev/rules.d/70-persistent-net.rules
## Make a log of the devices present during install
echo -e "${NETDEV} $(cat ${NETDEV}/address)\n" >>
/root/ksnet-devices
Re: [CentOS] CentOS 7, systemd and firewall-cmd
I'm on Fedora 22 Server which has this already: # cat /usr/lib/firewalld/services/rsyncd.xml Rsync in daemon mode Rsync in daemon mode works as a central server, in order to house centralized files and keep them synchronized. And also: # dnf provides /usr/lib/firewalld/services/rsyncd.xml Using metadata from Wed Feb 25 12:01:25 2015 firewalld-0.3.13-2.fc22.noarch : A firewall daemon with D-Bus interface providing a dynamic firewall Repo: @System So I can't tell you if this will work in your case and if there's some way within firewall-cmd to create these service files or not. Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7, systemd and firewall-cmd
On Wed, Feb 25, 2015 at 2:39 PM, Earl A Ramirez wrote: > On Wed, 2015-02-25 at 16:33 -0500, m.r...@5-cent.us wrote: >> Chris Murphy wrote: >> > firewall-cmd --add-service=rsyncd >> > >> firewall-cmd --add-service=rsyncd >> Error: INVALID_SERVICE: rsyncd >> >> Is there another place that there needs to be an rsyncd service file, >> whatever it's supposed to be named, *other* than where systemd wants it? >> >> mark >> > You can also specify the port > firewall-cmd --permanent --add-port=/tcp For what it's worth, anytime --permanent is used, the change is not dynamic, firewalld needs to be restarted. So instead, do the command twice, once with and once without --permanent. The order doesn't matter. -- Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
Add "rdblacklist=MODULE_NAME" to your append line in pxelinux.conf file. > Trying that next. It'll have to wait till tomorrow as we're under a serious blizzard/snow event right now and I'd like to get home before all of hell freezes over. However, question, if I blacklist the module, that means during kickstart it doesn't know it's there either, which would cause a 'network' definition for that interface to fail (and kickstart to stop) ... I think. This should get you into a usable state post-install so you can setup > additional interfaces. > My hope is that I don't have to do anything after it's done and reboots. The whole purpose of me doing this is in case something happens with the drive and I'm not here, someone can shove a new one in, reboot and let it go through the kickstart and be operational ten minutes later without them having done anything else. Maybe I'm aiming too damn high. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7, systemd and firewall-cmd
Chris Murphy wrote: > I'm on Fedora 22 Server which has this already: > > # cat /usr/lib/firewalld/services/rsyncd.xml > > > Rsync in daemon mode > Rsync in daemon mode works as a central server, in > order to house centralized files and keep them > synchronized. > > > > > And also: > # dnf provides /usr/lib/firewalld/services/rsyncd.xml > Using metadata from Wed Feb 25 12:01:25 2015 > firewalld-0.3.13-2.fc22.noarch : A firewall daemon with D-Bus > interface providing a dynamic firewall > Repo: @System > > > So I can't tell you if this will work in your case and if there's some > way within firewall-cmd to create these service files or not. Ok, *that's* the missing file. I looked in both /etc/firewalld/services and /usr/lib/firewalld/services, and there's no rsyncd in either. So, is this a CentOS bug, or upstream's problem? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7, systemd and firewall-cmd
On Wed, Feb 25, 2015 at 4:14 PM, wrote: > So, is this a CentOS bug, or upstream's problem? No idea. Guessing, it's probably missing upstream because at the time firewalld was stabilizing for RHEL7 it was brand new even on Fedora. So I'll bet a bunch of service files just aren't created. -- Chris Murphy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
On Wed, 25 Feb 2015 17:11:02 -0600, Ashley M. Kirchner wrote: Add "rdblacklist=MODULE_NAME" to your append line in pxelinux.conf file. Trying that next. It'll have to wait till tomorrow as we're under a serious blizzard/snow event right now and I'd like to get home before all of hell freezes over. However, question, if I blacklist the module, that means during kickstart it doesn't know it's there either, which would cause a 'network' definition for that interface to fail (and kickstart to stop) ... I think. It will if you try to configure the now non-existent interface. This should get you into a usable state post-install so you can setup additional interfaces. My hope is that I don't have to do anything after it's done and reboots. The whole purpose of me doing this is in case something happens with the drive and I'm not here, someone can shove a new one in, reboot and let it go through the kickstart and be operational ten minutes later without them having done anything else. Maybe I'm aiming too damn high. No, your not. One thing you might be doing though is being to concerned about ordering. The actual numbering of interfaces is, in most cases, purely cosmetic. So if you do not have another reason for needing a nice, logical ordering you should ignore it. Your use case is almost exactly why I went the route I did in the first place. Since this appears to be a recovery plan for a specific system then your best course is to accept the ordering as kickstart sees it and adjust your network config lines to compensate. As long as you have a udev rules file the ordering will not change on reboot. ___ 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] Kickstart with multiple eth devices
On Feb 25, 2015 4:19 PM, "Jason Warr" wrote: > It will if you try to configure the now non-existent interface. That's what I figured, so I can remove it from the kickstart file, no problem. The question then becomes, if kickstart doesn't configure it, what happens when the system reboots after install? It won't know what to do with that interface, correct? Is this a case where I will need to put an ifcfg-eth2 file in place during post-install? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] unable to umount
On 02/25/2015 07:48 AM, Leon Fauster wrote: Am 22.02.2015 um 16:12 schrieb Stephen Harris : Is the device NFS exported? I've seem that prevent umounting even though nothing shows up in the process list. Its a local "virtual" device (raid controller exports it as one device). I believe that Stephen was asking if you are exporting that filesystem via NFS to other systems. Check /etc/exports. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
On Wed, 25 Feb 2015 17:30:30 -0600, Ashley M. Kirchner wrote: On Feb 25, 2015 4:19 PM, "Jason Warr" wrote: It will if you try to configure the now non-existent interface. That's what I figured, so I can remove it from the kickstart file, no problem. The question then becomes, if kickstart doesn't configure it, what happens >when the system reboots after install? It won't know what to do with that interface, correct? Is this a case where I will need to put an ifcfg-eth2 file in place during post-install? Upon reboot the system *should* generate a base one for you as it will see it as a new interface. Not a big deal if it does not though, just create one yourself. You will want to add it to the udev rules file though. You can re-run the script I sent to do that if you want. At that point it should be eth2. Or you can edit the existing one by copying a line and changing the MAC and eth* to whatever you need. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Easy way to strip down CentOS?
On Feb 25, 2015 10:00 PM, "Peter" wrote: > > I haven't tried this, but see if it works: > yum shell > remove * > install @minimal > run > > I've not tried this to see the effect but don't forget in el6 there is the yum history database... yum history list will show all yum operations that have happened on the system. In principle you could do yum history rollback 1 ... That wouldn't clear up config data of course. For testing stuff VM use and templates or snapshots are essential tools. Or create a bare minimal kick start ... Doesn't take long to do a fresh install to a clean system that way. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
