date:20150225

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 li...@alteeve.ca 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
  ash...@pcraft.com 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
 uQttjHloI1SfhYN4D5AuQzeXFXTUM3IIkRr4KzGCmKezGi4s+wDrhm4goNmsOuiH

Re: [CentOS] Kickstart with multiple eth devices

2015-02-25 Thread Jim Perrin

overly trimmed

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] Easy way to strip down CentOS?

2015-02-25 Thread Brian Mathis

On Wed, Feb 25, 2015 at 2:04 PM, Niki Kovacs i...@microlinux.fr 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?

2015-02-25 Thread Frank Cox

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] Easy way to strip down CentOS?

2015-02-25 Thread John R Pierce


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] 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 
package_group', 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?




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?




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

[CentOS-announce] CESA-2015:0266 Important CentOS 6 thunderbird Security Update

2015-02-25 Thread Johnny Hughes


CentOS Errata and Security Advisory 2015:0266 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0266.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
10cf2774899a722583ccf83178b5b0c670cdfaa467e7def8038101d0512e89ac  
thunderbird-31.5.0-1.el6.centos.i686.rpm

x86_64:
72d284150fec9a4815ab4358299199052181d31d62bdd0e5a8fe57e925ff6165  
thunderbird-31.5.0-1.el6.centos.x86_64.rpm

Source:
5568672fb5bb86b79e4824e171f4c973ec6953defd67248f2c58b31ebf5d663b  
thunderbird-31.5.0-1.el6.centos.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net

___
CentOS-announce mailing list
CentOS-announce@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce

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 ash...@pcraft.com  
wrote:



Version 6.6 ...

On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin jper...@centos.org wrote:


overly trimmed

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] 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 ja...@warr.net 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 ash...@pcraft.com
 wrote:

  Version 6.6 ...

 On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin jper...@centos.org wrote:

  overly trimmed

 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 ash...@pcraft.com  
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 ja...@warr.net 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  
ash...@pcraft.com

wrote:

 Version 6.6 ...


On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin jper...@centos.org wrote:

 overly trimmed


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

Re: [CentOS] Kickstart with multiple eth devices

Version 6.6 ...

On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin jper...@centos.org wrote:

 overly trimmed

 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

[CentOS-announce] CESA-2015:0266 Important CentOS 5 thunderbird Security Update

2015-02-25 Thread Johnny Hughes


CentOS Errata and Security Advisory 2015:0266 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0266.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
03125dc617adf6e21a75514e135e82f08d90178f17f8d3e6c96d3cbc360b78ce  
thunderbird-31.5.0-1.el5.centos.i386.rpm

x86_64:
c638b9ceb5e6f217727fd392466c03bd268d668d167687215c87a8cbad9a4bcf  
thunderbird-31.5.0-1.el5.centos.x86_64.rpm

Source:
1985b7f18bb11b6dadb49cdb3a2dd8119767aab93f561789537319b754eb6d51  
thunderbird-31.5.0-1.el5.centos.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net

___
CentOS-announce mailing list
CentOS-announce@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce

Re: [CentOS] Easy way to strip down CentOS?

2015-02-25 Thread Steve Lindemann


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] 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

2015-02-25 Thread Earl A Ramirez

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=rsync_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?

2015-02-25 Thread Peter

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-virt] Video resolution for CentOS guest

2015-02-25 Thread Robert Nichols


On 02/24/2015 03:18 PM, Digimer wrote:


In my experience, once I set the resolution, it keeps that resolution
through reboots/logins. The initial login page sits at 1024x768, but
once logged in, it takes the resolution I asked for.


It's working that way for me now that I have installed kernel-ml-3.19.0
from elrepo in the guest.  With the 2.6.32 kernel that CentOS 6
provides, the behavior could best be described as confused.  I might
get a login screen at 1024x768 but with the content rendered as though
it were 1440x900 and the login dialog half off the edge of the screen.
Or, I might be logged in and looking at a screen properly drawn at
1024x768, but when I bring up the display preferences dialog it claims I
am already at 1440x900 and refuses to change.  And, occasionally when I
would try to change the resolution the display would lock up and, one
time, the whole X server crashed.

All that goes away with the guest running 3.19.0 kernel, and that also
makes sound work properly in the guest, so I'm happy now, at last.

--
Bob Nichols NOSPAM is really part of my email address.
Do NOT delete it.

___
CentOS-virt mailing list
CentOS-virt@centos.org
http://lists.centos.org/mailman/listinfo/centos-virt

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 ja...@warr.net 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 ash...@pcraft.com
 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 ja...@warr.net 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 
 ash...@pcraft.com
 wrote:

  Version 6.6 ...


 On Wed, Feb 25, 2015 at 1:17 PM, Jim Perrin jper...@centos.org wrote:

  overly trimmed


 On 02/25/2015 01:56 PM, Ashley M. Kirchner wrote:
  Ok, so some of this

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] Kickstart with multiple eth devices

On Wed, 25 Feb 2015 17:11:02 -0600, Ashley M. Kirchner ash...@pcraft.com  
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 Wed, 25 Feb 2015 17:30:30 -0600, Ashley M. Kirchner ash...@pcraft.com  
wrote:





On Feb 25, 2015 4:19 PM, Jason Warr ja...@warr.net 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] CentOS 7, systemd and firewall-cmd

On Wed, Feb 25, 2015 at 4:14 PM,  m.r...@5-cent.us 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


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 ash...@pcraft.com  
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 ja...@warr.net 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  
ash...@pcraft.com

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 ja...@warr.net 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

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.
snip
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] unable to umount

2015-02-25 Thread Gordon Messmer


On 02/25/2015 07:48 AM, Leon Fauster wrote:

Am 22.02.2015 um 16:12 schrieb Stephen Harris li...@spuddy.org:

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

2015-02-25 Thread Les Mikesell

On Wed, Feb 25, 2015 at 4:45 PM, Ashley M. Kirchner ash...@pcraft.com 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 ash...@pcraft.com  
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 ja...@warr.net 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  
ash...@pcraft.com 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 ja...@warr.net 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

On Wed, Feb 25, 2015 at 2:39 PM, Earl A Ramirez earlarami...@gmail.com 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=rsync_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

On Feb 25, 2015 4:19 PM, Jason Warr ja...@warr.net 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] 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 ja...@warr.net 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 ash...@pcraft.com
 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 ja...@warr.net 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

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
 ?xml version=1.0 encoding=utf-8?
 service
   shortRsync in daemon mode/short
   descriptionRsync in daemon mode works as a central server, in
 order to house centralized files and keep them
 synchronized./description
   port protocol=tcp port=873/
   port protocol=udp port=873/
 /service

 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

I'm on Fedora 22 Server which has this already:

# cat /usr/lib/firewalld/services/rsyncd.xml
?xml version=1.0 encoding=utf-8?
service
  shortRsync in daemon mode/short
  descriptionRsync in daemon mode works as a central server, in
order to house centralized files and keep them
synchronized./description
  port protocol=tcp port=873/
  port protocol=udp port=873/
/service

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

[CentOS-virt] Managing virt-manager's ever growing log file

2015-02-25 Thread Robert Nichols


I'm looking for suggestions on managing the ever growing log file from
virt-manager (~/.virt-manager/virt-manager.log).  All the info I've read
says that the log file is overwritten on each virt-manager startup.
That is demonstrably not true, at least for virt-manager-0.9.0-28.el6.
I see virt-manager startup entries going all the way back to the first
time I started it.

So, it looks like some arrangement with logrotate is in order.  Does a
running virt-manager have any facility for telling it to close and
reopen its log file, or do I have to use the copytruncate function of
logrotate?

--
Bob Nichols NOSPAM is really part of my email address.
Do NOT delete it.

___
CentOS-virt mailing list
CentOS-virt@centos.org
http://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS] Easy way to strip down CentOS?

2015-02-25 Thread James Hogarth

On Feb 25, 2015 10:00 PM, Peter pe...@pajamian.dhs.org 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

Re: [CentOS] Transparent GNOME Terminal in CentOS 7?