Ref: LaunchPad » Ubuntu » Questions » Question #108951

1. Check the lights. All green, now what?
2. Check the load. Normal.
3. Try hdparm. What? man hdparm
   

   // normal machine 1:
   $ sudo /sbin/hdparm -Tt /dev/md0:
    Timing cached reads:   15348 MB in  2.00 seconds = 7688.21 MB/sec
    Timing buffered disk reads:  808 MB in  3.19 seconds = 253.58 MB/sec
   
   // normal machine 2:
   $ sudo /sbin/hdparm -Tt /dev/md0:
    Timing cached reads:   18448 MB in  1.99 seconds = 9254.38 MB/sec
    Timing buffered disk reads:  1654 MB in  3.00 seconds = 551.33 MB/sec
   
   // problem machine:
   $ sudo /sbin/hdparm -Tt /dev/sdc:
    Timing cached reads:   27660 MB in  1.99 seconds = 13883.97 MB/sec
    Timing buffered disk reads:    8 MB in 14.64 seconds = 559.51 kB/sec

   Yes, we definitively have a problem. 500 kB/sec is cable modem speed, and I know my hard drive can store data faster than that… ok, now what?

4. Check the logs.
   1. Reboot into bios
   2. Check the event history
   3. Reboot into PERC bios
   4. Check the event history.
   5. Call Dell, the ones with all the answers and none of the obligation to share. They know the track-record of the hardware they sell, so when you call them up, they just sent you replacement parts for whatever everyone else’s problem was. This time, it worked.
5. The phone call to Dell went through the obvious: Reboot? Logs? Firmware? blah blah… Dell says they saw errors with disk 9. Ok, that’s something we didn’t see the first time around. Anyway…
6. Dell decided to send a new PERC card, new PERC cable, and because of the disk error, a new disk.

We decided to only replace the PERC card first, to see if that would solve the problem. It worked!

// problem machine after new PERC card:
$ sudo /sbin/hdparm -Tt /dev/sdc
 Timing cached reads:   25368 MB in  1.99 seconds = 12727.72 MB/sec
 Timing buffered disk reads:  256 MB in  3.00 seconds =  85.33 MB/sec

That’s 2 orders of magnitude improvement, but it’s not good enough. The other machines are doing better. Let’s change the look-ahead cache size.

// Set lookahead to 8192 blocks:
$ sudo /sbin/blockdev --setra 8192 /dev/sdc
$ sudo /sbin/hdparm -Tt /dev/sdc
/dev/sdc:
 Timing cached reads:   23988 MB in  1.99 seconds = 12035.05 MB/sec
 Timing buffered disk reads:  1202 MB in  3.00 seconds = 400.48 MB/sec

Now that’s what I’m talkin’ about!! Yes, 400 MB/sec is what we’re expecting for local disks. Call it a day, grab me a beer, celebrate — disaster thwarted.

When all was said and done, we double-checked the logs and didn’t find anything having to do with disk 9, so we figured it was all probably the card. It’s better not to rebuild the array in this case because we don’t use striping or mirroring… we need the space, and the “data” is regenerable (it’s processed output, not source data). I would have replaced the cable too, since there’s no penalty for doing so, but I wasn’t the tinkerer today.

So that’s it: bad PERC/6 card. It’s not the first bad enterprise part we’ve received from Dell. They need to work on that.

1. sudo vi /etc/dhcp3/dhclient.conf

   >>
   alias {
     interface "eth0";
     fixed-address 192.168.1.101;
     option subnet-mask 255.255.255.255;
   }
   <<

2. sudo dhclient -r
3. sudo dhclient

wget http://home.gdal.org/fwtools/FWTools-linux-2.0.6.tar.gz
sudo tar xzf FWTools-linux-2.0.6.tar.gz -C /usr/local
sudo /usr/local/FWTools-2.0.6/install.sh
sudo vi /etc/profile

# Add /usr/local/FWTools-2.0.6/bin_safe to the global $PATH 
pathmunge /usr/local/FWTools-2.0.6/bin_safe
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC

sudo cp /usr/local/FWTools-2.0.6/man/man1/* /usr/local/man/man1/
sudo cp /usr/local/FWTools-2.0.6/man/man3/* /usr/local/man/man3/
sudo cp /usr/local/FWTools-2.0.6/share/man/man1/* /usr/local/share/man/man1/
sudo cp /usr/local/FWTools-2.0.6/share/man/man3/* /usr/local/share/man/man3/
logout

Warning: You may break PHP!

The fwtools_env.* files could be copied to /etc/profile.d/, but if you’re running PHP, you’ll break the mechanism that loads php extensions. I don’t know why.

Reference:

FWTools: Open Source GIS Binary Kit for Windows and Linux

1. First, ensure mysql is installed: ls /etc/init.d/my*
2. Now, make mysql start on boot: sudo /sbin/chkconfig --level 35 mysqld on
3. Start the mysql server: sudo /etc/init.d/mysqld start
4. Make MySQL more secure: sudo /usr/bin/mysql_secure_installation
5. Log into mysql as root: mysql -u root -p [to be entered by prompt]
6. Add another mysql user:
   mysql> CREATE USER 'newuser'@'%' IDENTIFIED BY 'newuserpass';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER ON *.* TO 'newuser'@'%';
mysql> FLUSH PRIVILEGES;
7. Exit mysql: mysql> exit
8. Test: mysql -u <newuser> -p <newuserpass>

Installation (from source)

Go to http://www.kernel.org/pub/software/scm/git/ and pick the latest version (1.6.5.2), then from the command line, issue:

# Make a temporary directory from which we'll work
mkdir ~/gittmp
cd ~/gittmp
# Get the source, compile and intsall
wget http://www.kernel.org/pub/software/scm/git/git-1.6.5.2.tar.gz
tar xzf git-1.6.5.2.tar.gz
cd ~/gittmp/git-1.6.5.2
./configure
make
sudo make install
cd ~/gittmp
# Get and install the man pages
wget http://www.kernel.org/pub/software/scm/git/git-manpages-1.6.5.2.tar.gz
sudo tar xzf git-manpages-1.6.5.2.tar.gz -C /usr/local/share/man/
cd ~
rm -r ~/gittmp/

Testing

Now that we’ve got everything set up, go ahead and check that everything’s visible to your path.  Note: You may need to log back in for the settings to be read.
$ which git
/usr/local/bin/git
$ git config --help
--- man page retrieved ---

Configuration

Now we need to set some globals. These are used to identify you when pushing changes.
$ git config --global user.name "Scott Chacon"
$ git config --global user.email "schacon@gmail.com"

In a distributed environment, your workflow might go something like: A writes some code and commits. B pulls code, makes updates, commits. A updates local copy with B’s committed changes, continues development. The flow goes: get updates from peer, make changes, commit. Here’s an example:
alice: $ cd ~/project
alice: $ git init
alice: $ git add lib src README CHANGELOG
alice: $ git commit -m "Initialization"
bob: $ git clone /home/alice/project myrepo
bob: $ echo 'I made a change' >> CHANGELOG
bob: $ git commit -a -m "Appended changelog info"
alice: $ cd ~/project
alice: $ git pull /home/bob/myrepo master
alice: $ echo "Confirmed, changes were merged" >> CHANGELOG
alice: $ git commit -a -m "Merged bob's changes with some new additions"

Another setup might be to have a public repository for centralized access. It’s not really a central repository, but it’s the place where you push all your changes to from any machine you work on. In this way, anyone can go to exactly one place to get changes you’ve made, and you can work from any machine with git, using your own public repository as a starting point.
$ git clone --bare ~/proj proj.git
$ touch proj.git/git-daemon-export-ok
$ scp -r /proj.git user@host.com:/path/to/proj.git
Want to have access to the repo via http? Try this:
$ mv proj.git /var/www/html/repos/proj.git
$ cd /var/www/html/repos/proj.git
$ git --bare update-server-info
$ chmod a+x hooks/post-update
Now anyone can access your repository like so: $ git clone http://example.com/repos/proj.git

Prefer a private repository? It’s easier than the public setup.
You: $ git clone --bare /home/user/myrepo/.git /tmp/myrepo.git
$ scp -r /tmp/myrepo.git myserver.com:/opt/git/myrepo.git
Peer: $ git clone myserver.com:/opt/git/myrepo.git

So how do these shared repositories work?

1. clone to initialize local git revision management
2. modify/commit/revert/etc locally (1 or more times)
3. push up to the shared repository

Peer: … makes changes to source …
Peer: $ git commit -a -m "I made a few changes"
Peer: … continue editing until ready for consumption …
Peer: $ git commit -a -m "I made a few more changes"
Peer: $ git push ssh://yourserver.com/~you/proj.git master[:master]
You: $ git clone myserver.com:/opt/git/myrepo.git
You: … editing/conflict management/etc. …
You: $ git commit -a -m "Pretty up peer's changes (minor edits)"
You: $ git push ssh://yourserver.com/~you/proj.git master[:master]

Using Git on Windows

If you plan on using Git on Windows (Sure, why not? masochists pssht) you could install Git Extensions (Windows) from http://git-scm.com/tools. At least, that’s what I did. It was confusing as all hell, until I went through all possible alternatives that appeared easier than understanding what a remote is. The key to getting it all to work is setting up ssh keys so that you can auto-logon to whatever server has your git repositories with the ssh protocol. If you’re using the git protocol, I don’t think that applies. I could be wrong on this.

Once you’ve installed Git Extensions, load it up, do some general configuration (user.name, user.email, etc.), then select from the menu bar Remotes->PuTTy->Generate or import key. This assumes that you’ll be using PuTTY for all your ssh needs (if applicable). Anyway, generate a key and save the public key somewhere handy, save the private key somewhere safe. Now, using that pubkey, follow the advice for Setting up SSH Keys. You’re going to want to add that pub key to your authorized_keys on the git repo server. After that, make sure the PuTTY authentication agent is running (Remotes->PuTTy->Start authentication agent). A new icon should appear in your system tray. Right click on the new icon to “Add Key.” This key will be your private key. The agent handles the hand-shaking.

After doing all this the hard way, maybe you should just use the git protocol, but then again, I haven’t tried it myself.

Resources

Finally, it’s probably best to read Git’s HOWTOs and Tutorials.

• Git Installation
• Git Community Book (pgs. 40-44, 75-77)
• Git HOWTOs
• Git Tutorial (1of2)
• Git Tutorial (2of2)
• man git

Steps

1. Download latest JDK (jdk-6u16-linux-i586-rpm.bin) from Sun.
   Note: navigating Sun’s website and using their download accelerator is a PAIN.
2. chmod a+x jdk-6u16-linux-i586-rpm.bin
3. sudo ./jdk-6u16-linux-i586-rpm.bin
4. ls -l /usr/java
5. Create file /etc/profile.d/java-jdk.sh
   1. sudo vi /etc/profile.d/java-jdk.sh
   2. cat /etc/profile.d/java-jdk.sh
#!/bin/bash
export JAVA_HOME=/usr/java/latest
export JRE_HOME=/usr/java/latest/jre
export PATH=$JAVA_HOME/bin:$ANT_HOME/bin:$PATH


Answer:
Let’s first define a few things.

• localhost – Your regular, every-day machine. This machine will be making outbound calls to other machines, and is the originator of the ssh/scp requests.
• server – The machine to which one would want to log into via ssh, or scp files to.

First, generate the localhost’s key:
localhost$ ssh-keygen -b 4096 -t rsa
localhost$ scp ~/.ssh/id_rsa.pub server:~/.ssh/localhost.pub


We’ll go the fail-safe way, ensuring that an authorized_keys file exists, then we’ll cat the old with the new and replace the existing authorized_keys file:
server$ touch ~/.ssh/authorized_keys
server$ chmod 600 ~/.ssh/authorized_keys
server$ cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.bak
server$ cat ~/.ssh/authorized_keys.bak ~/.ssh/localhost.pub > ~/.ssh/authorized_keys


That’s all there is to it.

Question Why would you want to do that?

Answer:
Say you have a bash script that needs to copy files to another machine every time they are generated. The best way to do that is to scp them. Scp requires ssh authorization. By setting up these keys, you can allow your script to scp files securely without locking at the password prompt.

1. Logged in, then su, check which timezone your machine is currently using by executing `date`. You’ll see something like Mon 17 Jan 2005 12:15:08 PM PST, PST in this case is the current timezone.
2. Change to the directory /usr/share/zoneinfo here you will find a list of time zone regions. Choose the most appropriate region, if you live in Canada or the US this directory is the “America” directory.
3. If you wish, backup the previous timezone configuration by copying it to a different location. Such as
   mv /etc/localtime /etc/localtime-old
4. Create a symbolic link from the appropriate timezone to /etc/localtime. Example:
   ln -sf /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime
5. If you have the utility rdate, update the current system time by executing
   /usr/bin/rdate -s time-a.nist.gov
6. Set the ZONE entry in the file /etc/sysconfig/clock file (e.g. “America/Los_Angeles”)
7. Set the hardware clock by executing:
   /sbin/hwclock --systohc

The Process

Below is the order in which one would rename an entire name space. For demonstration, we’ll use a real example: Renaming :configuration: to :notes:, the very notes that you’re reading right now.

1. ssh into your wiki server
2. cd /var/www/default/wiki/
3. tar czf data-.tgz data
4. cd data (pwd is /var/www/default/wiki/data)
5. mv attic/configuration attic/notes (assuming notes doesn’t exist!!)
6. mv meta/configuration meta/notes (again assuming notes doesn’t exist.)
7. mv pages/configuration pages/notes (… again…)
8. grep -r configuration pages/notes/* (to find anything that might be broken)
9. foreach broken link: fix it. There’s a sed trick, but I don’t know it.
10. cross your fingers
11. visit your wiki website and enjoy.

In order to be able to simply dl(“Datascope.so”) in your PHP code, you first need to make sure Datascope.so is compiled and copied to the extension_dir, as specified in php.ini (ex: /usr/lib/php4).

Answer:
No: Stop right now. You’re not qualified to read this article.
Yes: Keep reading.

Notes

You’re not compiling the PHP source code for actual use, so please don’t install it. If you do, you run the risk of clobbering any pre-existing php installations, and overwriting previously compiled-in modules. The only reason why you ”make” PHP is so that the Zend libraries are properly initialized.

The PHP ”make” step may be avoidable, but given that the compile doesn’t affect system performance, I didn’t bother.

Paths should be changed to reflect your setup. If you don’t have the src/contrib/data/php/datascope code, you can get it from the contrib source at BRTT’s web site.

Contrib appears to be maintained by Indiana University.

Paths

• Antelope Bash Script ”/opt/antelope/4.9/setup.sh”
• Datascope Source ”/opt/antelope/4.9/src/contrib/data/php/datascope”
• PHP Source Code URL ”http://downloads.php.net/ilia/php-5.1.4.tar.bz2”
• PHP Modules Directory ”/usr/lib/php/modules/”

Compile and Install Steps

1. wget <PHP Source Code>
2. bunzip2 php-5.1.4.tar.bz2
3. tar xf php-5.1.4.tar
4. cd php-5.1.4
5. PHP_INC=`pwd`
6. export PHP_INC
7. ./configure
8. make
9. cd <Datascope Source>
10. source <Antelope Bash Script>
11. sudo make install
12. sudo cp Datascope.so <PHP Modules Directory>

PHP Script Example

Proper usage of the ”Datascope.so” module follows:

putenv( "PFPATH=/opt/antelope/4.9/data/pf" );
putenv( "ANTELOPE=/opt/antelope/4.9" );
 
set_include_path(
  get_include_path().PATH_SEPARATOR.getenv('ANTELOPE')."/data/php"
);
 
 
if( !extension_loaded( "Datascope.so" ) ) {
  dl( "Datascope.so") || exit( "Failed to load datascope.so" ) ;
}