Increase LVM Volume

I had the occasion to need some extra filespace on the LVM’d root partition of a RHEL(or CentOS) vm. This is how to do it:

First off, VMWare allowed me to create a second HDD on the fly while the vm was running (YAY!)

Once that was done, I rooted into the server and:

# echo “- – -” > /sys/class/scsi_host/host#/scan

(partprobe should also do the trick ??)

# fdisk -l

(Just to see that the new disk is available – in this case /dev/sdb)

# fdisk /dev/sdb

(create a new partition here)

# mkfs.ext3 /dev/sdb1

# vgs

(list the volume groups here)

# pvcreate /dev/sdb1

(add new physical volume)

# vgextend VolGroup00 /dev/sdb1

(extend my default volume group from the vgs command)

# vgs

(check to see pv and vg has another volume now)

# lvextend /dev/VolGroup00/LogVol00 /dev/sdb1

(extend my / volume by the entire size of /dev/sdb1)

# resize2fs /dev/VolGroup00/LogVol00

(resize filesystem to match vol size increase)

(requires a 2.6 kernel to resize while fs running)

I had the occasion to need some extra filespace on the LVM’d root partition of a RHEL(or CentOS) vm. This is how to do it:

# fdisk -l

(Just to see that the new disk is available – in this case /dev/sdb)

# fdisk /dev/sdb

(create a new partition here)

# mkfs.ext3 /dev/sdb1

# vgs

(list the volume groups here)

# pvcreate /dev/sdb1

(add new physical volume)

# vgextend VolGroup00 /dev/sdb1

(extend my default volume group from the vgs command)

# vgs

(check to see pv and vg has another volume now)

# lvextend /dev/VolGroup00/LogVol00 /dev/sdb1

(extend my / volume by the entire size of /dev/sdb1)

# resize2fs /dev/VolGroup00/LogVol00

(resize filesystem to match vol size increase)

(requires a 2.6 kernel to resize while fs running)

reference

I would just create an additional partition /dev/sda3 with the free
space. This partition can be added to the PVS:

pvcreate /dev/sda3
vgextend VolGroup00 /dev/sda3
lvextend -L20G /dev/VolGroup00/diskname
resize2fs      /dev/VolGroup00/diskname 20G

Depends of course on how your volume group is named. See the man pages
for details.

LVM in rescue mode

e2fsck:

Boot into rescue mode (in RHEL/Fedora this means putting in CD 1 and typing “linux rescue” at the boot prompt — but it’s essentially any minimal live CD). Rescue mode does not do anything with LVM by defualt: to activiate the volume groups, you need to issue these:

#lvm vgscan
#lvm vgchange -ay
#lvm lvs

lvs will simply display your volume group and logical volume names, use this output to issue the e2fsck command: e2fsck /dev/volumegroupname/logicalvolumename. Of course, pass what ever options ot e2fsck you normally would (like -y or -c).

reference:

How to configure static and dynamic NAT simultaneously

When static and dynamic NAT are configured together on the same router, static NAT takes precedence if a traffic flow matches both the configurations. Otherwise, dynamic NAT is used to create a new entry in the table and translate the traffic.

in our case…STATIC NAT rules (line 2-5) take precedence and dont rely on the DYNAMIC NAT rules (line 1)


1 ip nat inside source list PRIVATE-IP interface FastEthernet0/0 overload
2 ip nat inside source static 10.20.0.2 x08.x18.1x5.38
3 ip nat inside source static 10.20.0.3 x08.x18.1x5.39
4 ip nat inside source static 10.20.0.4 x08.x18.1x5.40
5 ip nat inside source static 10.20.0.21 x08.x18.1x5.42


referenced here:

Manually add Xwindows to an existing system. rather than blowing it away and re-installing.
Warning: yum is case-sensitive about the options

# yum groupinstall "X Window System" "GNOME Desktop Environment"

1.  install vncserver
# yum install vnc-server

2. create users unix account
# adduser joe
# adduser fred
# passwd joe
# passwd fred

3. make users vnc directory
# mkdir /home/joe/.vnc
# mkdir /home/fred/.vnc

4. generate users vncpassword
# vncpasswd /home/joe/.vnc/passwd
# vncpasswd /home/fred/.vnc/passwd

5. Edit /home/username/.vnc/xstartup, change windowmanager
uncomment/remove twn, add gnome-session
#vi /home/username/.vnc/xstartup
#twm &
gnome-session &

6. Edit /etc/sysconfig/vncservers, refer below.

VNCSERVERS="1:fred 2:joe"
# fred's VNC options
VNCSERVERARGS[1]="-geometry 1024x768"
# joe's VNC options
VNCSERVERARGS[2]="-geometry 1280x1024"


7. Enable the service with chkconfig vncserver on
8. Start the service with service vncserver start

reference:

how to install VMWare on CentOS 5.x

jump here:

aaaarrrgggghhh!!!!! customer’s client complaining that they cant get to the internet. they have an IP but doesnt seem to work for them. I check my dhcp server’s ip address range and did a quick ping scan on that range.. it turned out only few leases were online.

i checked the /var/log/messages and kept getting many DHCP IP offers from IP blocks not our own. hmmmm…

i did a quick google and found  that you can sniff the wire for any rogue dhcp

#/usr/sbin/tcpdump -i eth1 -l  “udp src port 67 and udp dst port 68″

20:00:36.590654 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1c:df:3d:d6:80, length: 300
20:00:36.694801 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 300
20:00:36.805844 IP 192.168.2.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 300
20:00:40.169506 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 302
20:00:41.589965 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1c:df:3d:d6:80, length: 300
20:00:41.694514 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 300
20:00:41.810429 IP 192.168.2.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 300
20:00:46.588929 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1c:df:3d:d6:80, length: 300
20:00:46.689106 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 300
20:00:46.804646 IP 192.168.2.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 300

i then re-applied the blocking of dhcp servers in the Canopy SM’s.. then the network went quite.

I did want to find who the customer doing this was but the above action is a blanket command so i guess its better. But i would like to kick the guy’s butt for messing up the network though

other option was to setup the linux box interface as a dhcp client and catch some of the illegal IP, or to run dhcp_probe and find out where its coming from.

I had a special requirement from a customer.. to allow him into his linux box even though he may be sourcing from a random ip address

solution:

- customer will create a dyndns.org account and run the dyndns updater from his laptop. this will auto update dyndns of his current ip

- server will run a dynamic firewall script via cron which will periodically resolve his myname.dyndns.org to the current ip, and the server will then update its iptables rule accordingly.

I found this script from Dave Horner very useful… jump here. I’ve modified his script a little so the customer can access only specific ports into  the server (ssh, ftp, vnc & web)

VNC by itself is not very secure as it transmits data across the network (lan, wan, internet). There is a way to let the VNC traffic ride inside an SSH session from your PC to the destination device (server or another PC).

Tunneling VNC using SSH and PuTTY

you need to know the VNC listening port at the destination device, usually between 5900-5905

Start PuTTY and configure it like as follows:

1. provide hostname (or ip address) of the destination box, use port 22
Saved Sessions: Use a proper name the describe the connection
Click on Save
2.  Click on Connection > SSH > Tunnels
Source port: Use the port on which VNC server is running (see step 1 – netstat command)
(ex. 5903)

Destination: IP address ot the VNC Server (your Linux box): Port
(ex. 192.168.100.34:5903)

Click on the “Add” button

Click back on “Session” again and then “Save” to store recent changes.

Click on “Open” then start the tunneling session. Use a regular user name and password to login to the Linux box.
3. Open VNC Viewer and type for server:

localhost:Display  (ex. localhost:3)  note… 3 refers to VNC listening port 5903 in this example.

VNC should start up but this time its traffic will be encrypted inside the SSH session. Proceed to use VNC as usual. Closing the putty.exe window will also close the encrypted VNC session.

reference:

I was working on an older Fedora Core4 server box for a customer. I found that the yum repo’s were broken already. I think the repo sources have been moved and the yum app just complains of not able to find some .xml file or something like that. I was actually trying to install bandwidthd, but all the dependencies were giving me flashbacks of “rpm hell”. If you’ve been around long enough to the pre-yum, pre-apt, pre-up2date era.. you’ll know how hard it is to install programs and find out that your missing a few dependencies and it goes on and on……

I had to disable all the repo’s that  came with the server in /etc/yum.repos.d

cd /etc/yum.repos.d

grep “enabled=1″ *.repo

replace all the “enabled=1″ with “enabled=0″ for all the repo files that had them. this will stop yum from looking at these repos. there should be a faster way to do this but i just edited them by hand.

vi /etc/yum.conf

added this, and saved changes..

[ArchivedFedora]
name=Archive Fedora Repo
baseurl=http://archive.fedoraproject.org/pub/archive/fedora/linux/core/4/i386/os/

Now yum should work as it is now pointing to the archived installer of Fedora Core4. Note that i had to manually find the archive.fedoraproject.org link via google and drilling down the directories to find the correct OS version. I saw alot of “older” linux OS versions at the http://archive.kernel.org/ site.. just in case you need to get to work on a different linux flavor. might save you some hair pulling