mcr at sandelman.ca
Wed, 25 Nov 2009
Port forwarding from something not your firewall
I have a number of web servers which want to express their port 443 to the world. These machines also have IPv6, and that's what I hope many clients will use. Since HTTPS servers can not do virtual hosting, and port 443 on CREDIL's firewall is already taken, what can I do?
We have other public IPs, with other (virtual) machines that have internal and external connections. I could use their port 443s.
I previously did this for port-119 (NNTP). I had set things up like:
iptables -A PREROUTING -d ${myexternalip}/32 -p tcp -m tcp --dport 119 -j DNAT --to-destination ${serverinternalip}:119
iptables -A POSTROUTING -d ${serverinternalip}/32 -p tcp -m tcp --dport 119 -j MASQUERADE
The first statement is relatively ordinary. Change the destination address. The second statement is annoying. It is critical on machines when the default route does not point at it. Basically, it changes the source IP that connects to the ${myinternalip} to be the internal address of the firewall.
This actually necessary even on the default route: without this, internal connections to port 119 do not work — this is because the internal machine sees a connection originating from the internal client IP, to the internal IP. The problem is that the internal client actually has a connection from it's IP, to the external IP of the firewall.
The above method works fine, except.... the internal machine sees the connection as being from the internal IP of the firewall. That really sucks from a point of view of logging!
How to solve it? The problem is that packets with an origin of port 443 needs to go to the other machine... this is what I did:
On the gateway machine:
iptables -A PREROUTING -d ${myexternalip}/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination ${serverinternalip}:443
On the target machine:
iptables -A OUTPUT -t mangle '!' -d ${myinternalnetwork}/24 -j MARK --set-mark 443
ip rule add fwmark 443 table 443
ip route add 0.0.0.0/0 via ${myinternaliP} table 443
It's very important that you set the mark using the mangle chain. It will not work on the NAT or the regular OUTPUT chain!
The result is now that packets with origin port 443, go via this alternate firewall, and the web server itself will see the correct originating IP.
posted at: 13:21 | path: /howto | permanent link to this entry
Mon, 23 Nov 2009
Apparently, at Canadian Tire, and online, if I want multicolour Xmas lights (ideally LEDs), that I have to have a green cord. Only white cords are with white LEDs.
I considered buying one of each and moving the "bulbs", but many of the systems are not socketed.
I want Xmas lights I can put up on the house, staple in, and LEAVE there.
posted at: 18:16 | path: /howto | permanent link to this entry
Thu, 13 Aug 2009
Using mysqldump to do automated backups
One of my annoyances of MySQL is that all authentication is "password" based. I very much prefer PostgresQL's use of Unix sockets, such that if you login as the "postgres" user (or whatever user you are running the cluster as), you are effectively root.
So, one has passwords for the root database user spread all over scripts when you have a MySQL install. Very annoying.
On debian systems (including Ubuntu and JEOS), there is a special userid created called "debian-sys-maint", the init scripts use this ID for shutting down. The password is randomly created and is stored into /etc/mysql/debian.cnf. Read /etc/init.d/mysql if you want details.
How do use this with mysqldump? it does not have a --config option.
Finally, after a lot of googling, I came across the page:
it says:
defaults-extra-file The file specified with --defaults-extra-file=path, if any
So, mysqldump can be told to read additional config files!
sudo mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --database myfoo
posted at: 15:59 | path: /howto | permanent link to this entry
Tue, 30 Dec 2008
Converting DVD into small chunks for Youtube
A friend dropped a multiple-hour DVD at my house, transfered from an 8mm tape. "Can you upload to Youtube?"
I mounted it:
mount /cdrom cd /cdrom/video_ts
and then I found some space to put the results (an NFS server), and I proceeded to run:
ffmpeg -i vts_01_1.vob -r 16 -ss 0 -t 300 /ssw/morevideos/tim/part1.mp4 ffmpeg -i vts_01_1.vob -r 16 -ss 300 -t 300 /ssw/morevideos/tim/part2.mp4 ffmpeg -i vts_01_1.vob -r 16 -ss 600 -t 300 /ssw/morevideos/tim/part3.mp4 ffmpeg -i vts_01_1.vob -r 16 -ss 9000 -t 300 /ssw/morevideos/tim/part4.mp4
I could write a shell script to do this for me, but I typed it out. ffmpeg said to me:
Input #0, mpeg, from 'vts_01_1.vob': Duration: 00:14:34.8, start: 0.227022, bitrate: 9741 kb/s Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480, 9300 kb/s, 29.97 fps(r) Stream #0.1[0x80]: Audio: ac3, 48000 Hz, stereo, 256 kb/s Output #0, mp4, to '/ssw/morevideos/tim/part4.mp4': Stream #0.0: Video: mpeg4, yuv420p, 720x480, q=2-31, 200 kb/s, 16.00 fps(c) Stream #0.1: Audio: aac, 48000 Hz, stereo, 64 kb/s
and the part4.mp4 was actually empty, because the _1.vob file only had about 15 minutes of video in it. I then went on to the _2.vob file.
The results are at: http://www.youtube.com/watch?v=FT1-caLBJ9c
posted at: 22:32 | path: /howto | permanent link to this entry
Fri, 26 Oct 2007
How to extend a file system using LVM/XEN
You have a nifty XEN domU running on top of an LVM backed dom0. You run out of space, and you need to extend. It's not hard, but it can be tedious if you don't want to the domU down.
The hardest part is making sure that there are no processes using the partition you want to extend, as you have to umount it. While ext2online (available in RH kernels, but not, as of 2.6.18, stock) permits you to expand the file system, unfortunately, with xen 3.1.0, extending the Logical Volume underneath does not communicate the new length to the domU.
Usually, people miss the NFS exports. To unexport temporarily (which does screw any client using it), you can use exportfs. You need to give it the IP addresses (possibly with netmasks) that you wish to remove. They have to match. This is still easier than running exportfs -a -u, editing the /etc/exports and running exportfs -a, as it doesn't screw quite so many NFS clients.
In these examples, tbm800 is a guest domU, which happens to also
be an NFS server. airbus is the dom0.
tbm800-[~] root 1 #df -H /proj/thintropy/skeletons Filesystem Size Used Avail Use% Mounted on /dev/sde5 11G 8.0G 2.1G 80% /proj/thintropy/skeletons tbm800-[~] root 7 #umount /proj/thintropy/skeletons umount: /proj/thintropy/skeletons: device is busy umount: /proj/thintropy/skeletons: device is busy tbm800-[~] root 9 #exportfs -u 192.168.7.169:/proj/thintropy/skeletons tbm800-[~] root 10 #umount /proj/thintropy/skeletons
Now, we need to know what the backend block device which was used
to mount the device. Unfortunately, xm block-list does not
show us anything useful, but it's in the logs:
airbus-[/var/log/xen] root 10 #grep tbm800 xend.log | grep skeletons | grep DevController
[2007-10-09 09:32:02 xend 3682] DEBUG (__init__:1072) DevController: writing
{'domain': 'tbm800', 'frontend': '/local/domain/1/device/vbd/2117', 'dev':
'sde5', 'state': '1', 'params': '/dev/AirbusGroup0/tbm800skeletons', 'mode':
'w', 'online': '1', 'frontend-id': '1', 'type': 'phy'} to
/local/domain/0/backend/vbd/1/2117.
[2007-10-09 10:43:49 xend 27521] DEBUG (__init__:1072) DevController: writing
{'domain': 'tbm800', 'frontend': '/local/domain/14/device/vbd/2117', 'dev':
'sde5', 'state': '1', 'params': '/dev/AirbusGroup0/tbm800skeletons', 'mode':
'w', 'online': '1', 'frontend-id': '14', 'type': 'phy'} to
/local/domain/0/backend/vbd/14/2117.
Note the 2117. We need to know the domain-ID, as well.
airbus-[/var/log/xen] root 11 #xm list tbm800 Name ID Mem(MiB) VCPUs State Time(s) tbm800 14 192 1 -b---- 7812.5 airbus-[/var/log/xen] root 12 #xm block-detach Error: 'xm block-detach' requires 2 arguments. Usage: xm block-detach <Domain> <DevId> Destroy a domain's virtual block device. [1] 31565 exit 1 xm block-detach airbus-[/var/log/xen] root 13 #xm block-detach 14 2117
Now, we can manipulate the LV:
airbus-[/var/log/xen] root 14 #lvextend -L +10G /dev/AirbusGroup0/tbm800skeletons Extending logical volume tbm800skeletons to 20.00 GB Logical volume tbm800skeletons successfully resized
Next we can attach the block device again. We need to know some details, but they are in the config file:
airbus-[/var/log/xen] root 15 #grep tbm800skeletons /etc/xen/tbm800
'phy:/dev/AirbusGroup0/tbm800skeletons,sde5,w'
airbus-[/var/log/xen] root 16 #xm block-attach
Error: 'xm block-attach' requires between 4 and 5 arguments.
Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode>
Create a new virtual block device.
[1] 31646 exit 1 xm block-attach
airbus-[/var/log/xen] root 17 #xm block-attach 14 phy:/dev/AirbusGroup0/tbm800skeletons sde5 w
On the domU, again, now we can resize things:
tbm800-[~] root 12 #e2fsck -f /dev/sde5 e2fsck 1.40-WIP (14-Nov-2006) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sde5: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sde5: 323289/1310720 files (1.4% non-contiguous), 1979906/2621440 blocks
And finally, the resize operation:
tbm800-[~] root 14 #resize2fs /dev/sde5 resize2fs 1.40-WIP (14-Nov-2006) Resizing the filesystem on /dev/sde5 to 5242880 (4k) blocks. The filesystem on /dev/sde5 is now 5242880 blocks long. tbm800-[~] root 15 #mount -a tbm800-[~] root 16 #df -H /proj/thintropy/skeletons Filesystem Size Used Avail Use% Mounted on /dev/sde5 22G 8.0G 13G 40% /proj/thintropy/skeletons tbm800-[~] root 17 #exportfs -a
The device is now 22G in size.
posted at: 00:59 | path: /howto | permanent link to this entry
Wed, 27 Dec 2006
When my Toshiba laptop died, I knew that the hard disk I had was still good, and so I got the UltraBay HD adapter to go with my IBM Thinkpad. When the Thinkpad arrived, I declined the MS EULA that the laptop booted up with, turned it off again, and swapped in my old HD. Thanks to the fact that Linux (and NetBSD) do not have stupidly motherboard specific kernels (it's EVEN WORSE with Vista. See: http://ars.userfriendly.org/cartoons/?id=20061106&mode=classic ) I can just move my hard disk to a new system.
Anyway, in fall 2005, when my motherboard blew up, it took my hard disk as well (I'd reformatted the IBM HD, and was now using that). I replaced the hard disk, and still have to RMA the original, and wound up with a 60G drive inside the laptop, and a 40G drive in the bay. Most of the time, this is the right combination, with the CDrom in the docking station. The I/O path to the ultrabay is a bit faster than the I/O path to the docking station, although you can't boot from a cdrom in the docking station.
The question arises: where do you put your music? When I'm at my home office, the music is accessed over HTTP, so I don't need a local copy. When I'm travelling, I'm often on battery. I'd prefer to have my spare UltraBay battery in the bay rather than my spare disk. On sensible airplanes, and on VIA rail, you get power, so you don't need the battery. I think that I've now concluded that putting my music on my second disk is okay, but up to now, I haven't done that.
The second problem is where to put the master Linux Kernel git tree. Until this past summer, with "git clone -s" (more on that later), one wanted to have kernel git trees on the same partition as one's experimental trees, since they could share with hard links. I made the decision that if I was doing core kernel development (vs Openswan + UML), I probably had test machines, so I have power. So I put my kernel in /mara1/git.
The result is that up to today I had five ~8G partitions on my external drive. This is big enough to be useful for work like git, but small enough that I won't loose too much at a time, and I can do backups reasonably easily. Generally, I like to either backup everything on a partition, or nothing. So if I have data on a partition which can trivially be recovered from the internet, I may not back it up.
This means that my laptop (whose name is "marajade") looks like:
PRIMARY DISK / + /usr - operating system /boot - kernels (100M) /home - my home directory /var - logs and administrative files /corp - my corporate data, projects, etc. /sandel - local programs, source code and customization /mara6 - project space (mostly openswan + UML as it turns out) /mara7 - customer project space (some kernels) /mara8 - ccache, spam folders, music
SECONDARY DISK /mara1 - many git trees /mara2 - more openswan + other stuff sandboxes /mara3 - random data /mara4 - freebsd and other code, more customer project space /mara5 - backups... never really used.
The problem with any partitioning scheme other than "put everything in one partition", is that one can run out of space on one partition, and still have space elsewhere. This is very difficult for new users to deal with, but it can be very annoying for experienced users as well.
Of course, with everything in one partition there are other problems: you can have logs run away and eat ALL the disk space, and then you may have a problem, and you may not notice for perhaps even YEARS. If you have a file system error, you are out of luck. If you re-install your operating system, you likely LOOSE a lot of your data.
I had my secondary disk partitions mounted via the LABEL= hack so that they would be found whether the second disk was hdc (ultrabay), or hde (docking station). I marked them noauto, so if they aren't present life doesn't end, and have a boot script that runs mount on them instead.
After using the Logical Volume Manager tools a bunch to deal with Xen, I realized that I could have the best of both solutions. I wondered at first, if I could create a single volume group, and sometimes not have one physical volume, and perhaps could simply force LVs to be on one physical volume or another, and migrate stuff around as I need it. That doesn't work, unfortunately, see: http://www.sandelman.ca/mcr/blog/2006/05/24#how_to_unscrew_your_lvm
My solution is two volume groups, and I was able to move data around a bit to free up a partition to make my first physical volume for each volume group, and then restore data. The end result is that I now have a /corp/projects/SOMETHING (primary disk), and /corp/projects/SOMETHING2 (secondary disk), for a lot of project related data. Note that I didn't move my operating system or personal data. I'm still a bit hesistant about LVM, and in particular, my local kernel source (which I'd need to build LVM modules!) is accessible without LVM.
My new /etc/fstab:
/dev/hda5 / ext3 defaults,errors=remount-ro 0 1 /dev/hda1 /boot ext2 defaults 0 2 /dev/hda12 /corp ext3 defaults 0 2 /dev/hda8 /home ext3 defaults 0 2 /dev/hda10 /mara6 ext3 defaults 0 2 /dev/hda9 /sandel ext3 defaults 0 2 /dev/hda6 /usr ext3 defaults 0 2 /dev/hda7 /var ext3 defaults 0 2 LABEL=UmlRoot /uml ext3 defaults 0 0 LABEL=CACHE /cache ext3 defaults 0 0 LABEL=DistrosKernel /distros/kernel ext3 defaults 0 0 LABEL=ProjectOpenswan /corp/projects/openswan ext3 defaults 0 0 LABEL=ProjectXelerance /corp/projects/xelerance3 ext3 defaults 0 0 LABEL=ProjectCobbix /corp/projects/cobbix ext3 rw,noauto,user,exec,defaults 0 0 LABEL=ProjectVpnx /corp/projects/vpnx ext3 rw,noauto,user,exec,defaults 0 0 LABEL=ProjectFreeradiu /corp/projects/freeradius ext3 rw,noauto,user,exec,defaults 0 0 LABEL=ProjectMisc /corp/projects/Misc ext3 rw,noauto,user,exec,defaults 0 0 LABEL=UmlRoot2 /uml2 ext3 rw,noauto,user,exec,defaults 0 0 LABEL=ProjOpenswan2 /corp/projects/openswan2 ext3 rw,noauto,user,exec,defaults 0 0 LABEL=ProjectsHifn2 /corp/projects/hifn2 ext3 rw,noauto,user,exec,defaults 0 0 LABEL=ProjectCroquet /corp/projects/opencroquet ext3 rw,noauto,user,exec,defaults 0 0
lvm> vgs VG #PV #LV #SN Attr VSize VFree MaraMainDisk 3 5 0 wz--n- 18.50G 4.50G MaraUltraBay 5 8 0 wz--n- 35.39G 17.42G
lvm> lvs LV VG Attr LSize Origin Snap% Move Log Copy% CACHE MaraMainDisk -wi-ao 3.00G DistrosKernel MaraMainDisk -wi-ao 4.00G ProjectOpenswan MaraMainDisk -wi-ao 3.00G ProjectXelerance MaraMainDisk -wi-ao 2.00G UMLROOT MaraMainDisk -wi-ao 2.00G ProjectCobbix MaraUltraBay -wi-ao 1000.00M ProjectCroquet MaraUltraBay -wi-ao 2.00G ProjectVpnx MaraUltraBay -wi-ao 2.00G ProjectsFreeradius MaraUltraBay -wi-ao 1.00G ProjectsHifn2 MaraUltraBay -wi-ao 6.00G ProjectsMisc MaraUltraBay -wi-ao 2.00G ProjectsOpenswan2 MaraUltraBay -wi-ao 2.00G UMLROOT2 MaraUltraBay -wi-ao 2.00G
marajade:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda5 1829159 458651 1272915 27% /
udev 10240 96 10144 1% /dev
devshm 255272 0 255272 0% /dev/shm
/dev/hda1 112883 61155 45706 58% /boot
none 65536 160 65376 1% /tmp
none 65536 0 65536 0% /ramdisk
none 4807056 704176 3858696 16% /var/run
/dev/hda12 7692876 6294116 1007984 87% /corp
/dev/hda8 7692876 2754784 4547316 38% /home
/dev/hda9 7692876 2200808 5101292 31% /sandel
/dev/hda6 7692876 2652548 4649552 37% /usr
/dev/hda7 4807056 704176 3858696 16% /var
/dev/mapper/MaraUltraBay-ProjectCobbix
991949 627375 313374 67% /corp/projects/cobbix
/dev/mapper/MaraUltraBay-ProjectsMisc
2064208 828640 1130712 43% /corp/projects/Misc
/dev/mapper/MaraUltraBay-ProjectsFreeradius
1032088 102260 877400 11% /corp/projects/freeradius
/dev/mapper/MaraUltraBay-ProjectsOpenswan2
2064208 301440 1657912 16% /corp/projects/openswan2
/dev/mapper/MaraUltraBay-UMLROOT2
2064208 217764 1741588 12% /uml2
/dev/mapper/MaraMainDisk-CACHE
3096336 1927832 1011220 66% /cache
/dev/mapper/MaraUltraBay-ProjectVpnx
2064208 979912 1000412 50% /corp/projects/vpnx
/dev/mapper/MaraUltraBay-ProjectCroquet
2064208 136516 1822836 7% /corp/projects/opencroquet
/dev/mapper/MaraMainDisk-UMLROOT
2064208 217768 1741584 12% /uml
/dev/mapper/MaraMainDisk-ProjectOpenswan
3096336 2048528 890524 70% /corp/projects/openswan
/dev/mapper/MaraMainDisk-ProjectXelerance
2047379 1902 1961591 1% /corp/projects/xelerance3
/dev/mapper/MaraUltraBay-ProjectsHifn2
6192704 4020112 1983852 67% /corp/projects/hifn2
/dev/mapper/MaraMainDisk-DistrosKernel
4128448 2743844 1342664 68% /sandel/distros/kernel
What would be nice
It would be neat if there was a way to move a logical volume from one volume group to another, and do this in the background. I would do this by turning the logical volume into a RAID-1 ( http://en.wikipedia.org/wiki/RAID ), and letting the RAID-1 mirror the data. The trick would be to do this using the dm-mapper, changing the "plumbing" underneath, and when it was done, remove the RAID-1 settings, leaving the file system layer ignorant of the change.
It would also be nice to be able to resize the partitions without unmounting them. I think that one of XFS or ReiserFS-4 can do this. I use ext3 at present.
How I use git-clone
The new thing about git clone -s, is that it doesn't use hard links, or
soft-links, but instead sets up .git/objects/info/alternatives. This
effectively reduces the cost of a kernel .git tree to the space for the
checked out files (about 50M for Linux) and objects. I move my "Linus
Torvalds" git tree to /distros/kernels/linus.git, and git clone it. I put
that master tree on my primary disk, because then I always have it, while I
can put as many kernels with object files on per-project places as I go.
(/distros/kernels is an example of stuff that I wouldn't bother backing up,
btw.)
It is my intention to even create partitions for specific projects as I need them, and remove them when I am done. The question will be, how in such a dynamic world, will I get all my backups to do the right thing.
posted at: 20:15 | path: /howto | permanent link to this entry
Wed, 24 May 2006
I just moved some patches to the Linux kernel from a 2.6.15 base to a 2.6.16.18 base.
This is how I did it:
- I started by going to my copy of the Linus Torvalds tree, and updating it.
% cd /mara1/git/torvalds % cg-branch-ls origin http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git % cg-updateto get the latest code down, just in case.
- I then cloned the tree.
% cd /mara1/git % cg-clone torvalds stable2.6.16.yCloning it like this lets it use hard links!
- I then added the 2.6.16 branches:
% cd stable2.6.16.y % cg-branch-add stable2.6.16.y http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git % cg-update stable2.6.16.y
- I then added the stable 2.6.16 tree to my working tree. I prefer to have
seperate trees like this so that I can poke around. I could added the stable branch to my torvalds tree, btw.
% cd /mara1/git/klips-ocf % cg-branch-add stable /mara1/git/stable2.6.16.y % cg-fetch stable
- Then I ran git rebase.
% cg-tag ocf_v2.6.15 % git rebase stable ocf % cg-branch-chg origin git+ssh://git.openswan.org/public/scm/klips.git#ocf_v2.6.16
I made sure to leave a tag, because "git rebase" changes the branch, and you might not be able to get it back.
posted at: 20:17 | path: /howto | permanent link to this entry
I had a system with a single 40Gb PATA drive in it. It had two 160GB SATA drives in it too, but the SATA controller on the motherboard was not supported yet by Fedora Core 5. (It's a VIA controller. VIA has drivers, but they aren't stable yet)
I got a 2-port Adaptec SATA controller, hooked it up while moving the machine to a 3U case, and booted. Great, everything works.
I then added the two new volumes to my "VolGroup00", and took the system down to the colo. Oh. shit. It won't boot.
Why? because the initrd for the system didn't have the Adaptec controller, so the system couldn't see the extra physical volumes, so it couldn't construct the logical volume group, so it couldn't find the "root" disk.
DAMN.
I booted a Fedora Core 5 rescue CD. (I am, btw, looking for a 30-50Mb image that I can stick on /boot, and invoke from grub, which would be a serial-console happy rescue image. It should have sshd, and be able to dhcp an address ideally.... I was going to take apart some CD-based .iso, but I haven't done hat yet)
I then fixed this by running mkinitrd properly, and the system found the right disks, and booted.
I thought: I don't want all my disks in the same volume group if a screw up will prevent the system from booting.
I came across the command "pvremove", which I proceeded to run on /dev/sda1 and /dev/sdb1. OOPS. System won't boot again, because I actually destroyed the physical volumes (from LVM's point of view), not removed them.
Another run through with the rescue CD. Need to figure out what to do. The command "lvm" is nice, because as a wrapper around all the commands, it also tells you quickly what are actual commands and not.
The solution:
lvm> vgreduce VolGroup00 --removemissing Couldn't find device with uuid 'nwprFB-HWF3-GRL7-ow4P-JUXO-Zp2J-ckZ8fe'. Couldn't find all physical volumes for volume group VolGroup00. Couldn't find device with uuid 'nwprFB-HWF3-GRL7-ow4P-JUXO-Zp2J-ckZ8fe'. Couldn't find all physical volumes for volume group VolGroup00. Couldn't find device with uuid 'nwprFB-HWF3-GRL7-ow4P-JUXO-Zp2J-ckZ8fe'. Couldn't find device with uuid 'tLpEoy-X3jh-7QgU-oWTY-dmrh-4dKx-jCOLVm'. Wrote out consistent volume group VolGroup00
Now, I have:
trout-[~] root 1 #lvs LV VG Attr LSize Origin Snap% Move Log Copy% FlorinRoot GuestGroup00 -wi-a- 5.00G LogVol00 VolGroup00 -wi-ao 35.19G LogVol01 VolGroup00 -wi-ao 1.94G trout-[~] root 2 #pvs PV VG Fmt Attr PSize PFree /dev/hdb2 VolGroup00 lvm2 a- 37.16G 32.00M /dev/sda1 GuestGroup00 lvm2 a- 149.05G 144.05G /dev/sdb1 GuestGroup00 lvm2 a- 149.05G 149.05G trout-[~] root 3 #vgs VG #PV #LV #SN Attr VSize VFree GuestGroup00 2 1 0 wz--n- 298.09G 293.09G VolGroup00 1 2 0 wz--n- 37.16G 32.00M
posted at: 20:11 | path: /howto | permanent link to this entry
Tue, 02 May 2006
installing git/cogito on cygwin
go to http://sources.redhat.com/cygwin and install the cygwin system.
It runs a setup program that downloads core pieces that gives you bash, gcc, etc. under Windows. While you won't be compiling the code on your windows desktop/laptop, you may want to browse documents or code.
get and install cygwin (http://www.cygwin.com (http://www.cygwin.com/setup.exe)) when you are asked for the components make shure you install curl, curl-devel, openssl, make, gcc, openssh, cvs, openssl-devel, wget, zlib. Run the cygwin setup program a second time if you missed something.
wget http://kernel.org/pub/software/scm/cogito/cogito-0.17.2.tar.gz wget http://kernel.org/pub/software/scm/git/git-1.3.1.tar.gz zcat git-1.3.1.tar.gz | tar xf - cd git-1.3.1 make make install cd .. zcat cogito-0.17.2.tar.gz | tar xf - cd cogito-0.17.2 make make install ssh-keygen cat .ssh/id_rsa.pub
The key that is displayed should be copied your server.
posted at: 05:13 | path: /howto | permanent link to this entry
