slugman's questions

So I just extended the VG on my server. Basically, the local disk is 300GB. I initially created two partitions: sda1 is a primary partition, with ext4 assigned to /boot; sda2 is where 74G VG resides (vg is server hostname).

So I had an extra 225G left. I went ahead and created a third primary partition sda3, and after succesfuly creating a VG on sda3, I used lvextend to extend the size of my lv by 1GB.

So, here are the commands I ran after fdisk:

pvcreate /dev/sda3
vgextend hostname /dev/sda3
lvextend -L+1G /dev/hostname/home

For which I received the following output:

Extending logical volume home to 2.00 GiB
Logical volume home successfully resized

However, the prompt has been stuck on the last message now for several hours. My attempts to perform an lvscan / or lvdisplay fail with the following error:

/var/lock/lvm/V_hostname: flock failed: Interrupted system call
Can't get lock for hostname
Skipping volume group hostname

So my question is, do you think my system actually succesfully performed the resize? Am I safe to reboot? Or should I wait around a little longer? This is LVM2, so I was under the assumption that I could perform these operations live while the lv is actively mounted. I know this depends on type of filesystem you're using, but I figured I was good since I am on ext4.

I noticed in my routes output in RHEL6 (and most 2.6.x series Linux), for every interface I see the creation of the following route in my kernel routing table:

169.254.0.0     0.0.0.0         255.255.0.0     U     1018   0        0 bond0
169.254.0.0     0.0.0.0         255.255.0.0     U     1019   0        0 bond1
169.254.0.0     0.0.0.0         255.255.0.0     U     1020   0        0 bond2

My understanding is that the link-local addresses are used when auto address configuration fails (when dhcp breaks). When dhcp fails the system will assign itself an available link-local address (more or less).

In your guy's experience, are these necessary? I'm utilizing manual/static IP assignment in my network, so there is no auto-address configuration. Therefore, there is no chance that auto-address configuration would fail. Can I safely remove these routes?

Or is there some other hack/reason I should keep these guys?

Diego

I have a simple question that I'm trying to wrap my head around. I know this requires knowledge of my internal network, but at a glance, what do you guys think..

I cannot ping a host in my network (nor can I arping the host), however nmap can detect the host.

Does this mean I have connectivity to the host? Or am I dead in the water?

I have a route to the host in my routes, and iptables is disabled on my server (rhel6).

192.168.6.0     0.0.0.0         255.255.255.128 U     0      0        0 bond2

--- 192.168.6.5 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5212ms

--- 192.168.6.6 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1097ms

Nmap scan report for mdc001 (192.168.6.5)
Host is up (0.00017s latency).
MAC Address: 12:34:56:78:90:AB (Hewlett Packard)
Nmap scan report for mdc002 (192.168.6.6)
Host is up (0.00018s latency).
MAC Address: 12:34:56:78:90:AB (Hewlett Packard)

(MAC's modified for obscurity).

What gives? Am I able to communicate with the host or not? Also, there were link-local routes for the interface on that network (bond2), but I removed them just in case.

Diego

I've almost got my AD integration working completely on my OpenSUSE 12.1 server. I have a OpenSUSE 11.4 system successfully integrated into our AD environment. (Meaning, we use LDAP to authenticate to AD directory via Kerberos, so we can login to our *nix systems via AD users, using name service caching daemon to cache our passwords and groups).

Also, important to note these systems are in our LAN, SSL authentication is disabled.

I am almost all the way there. nss_ldap is finally authenticating with LDAP server (as /var/log/messages shows), but right now, I have another problem:

getent passwd and getent shadow fails (shows local accounts only), but getent group works! getent group shows all my ad groups!

I copied over the relavent configuration files from my working OpenSUSE 11.4 box:

 /etc/krb5.conf
 /etc/nsswitch.conf
 /etc/nscd.conf
 /etc/samba/smb.conf
 /etc/sssd/sssd.conf
 /etc/pam.d/common-session-pc
 /etc/pam.d/common-account-pc
 /etc/pam.d/common-auth-pc
 /etc/pam.d/common-password-pc

I didn't modify anything between the two. I really don't think I need to modify anything, because getent passwd, getent shadow, and getent group all works fine on the OpenSUSE11.4 box.

Attempting to restart nscd service unfortunately didn't do much, and niether did running /usr/sbin/nscd -i passwd.

Do any of you admin-gurus have any suggestions?

Honestly, I'm happy I made it this far. I'm almost there guys!