How to reset a mysql primary key

Sometimes you want to reset your auto_increment primary key in mysql so that the newly inserted records start at 1. In my testing database, for convenience, I want to do this (never mind why. Just live with it. Any smug comments about depending on fixed primary key values are noted, so no need to add them. Unless you're a dick).

Resetting the primary key is straightforward:

alter table foo AUTO_INCREMENT = 1

How to kill a linux process

The Kill command does exactly what it sounds like: it kills a process. It sends a signal to a process to kill itself. Here are three ways to kill a linux process:

Step one: find the process

Suppose you wanted to kill a certain httpd process. First, you need to find it:

# ps -ef | grep firefox
2073 ?        Sl     1:07 /usr/lib/firefox-3.5.3/firefox

There are other ways to effectively kill a process — killing a process by name, killing a process by specifying part of the name, killing a process by pointing out the process with cursor etc.,

In this article, let us review 4 ways to kill a process.


1. Kill Command – Kill the process by specifying its PID

All the below kill conventions will send the TERM signal to the specified process. For the signals, either the signal name or signal number can be used. You need to lookup the pid for the process and give it as an argument to kill.

$ kill -TERM pid

$ kill -SIGTERM pid

$ kill -15 pid
Example: Kill the firefox process.



$ ps -ef | grep firefox
2073 ? Sl 1:07 /usr/lib/firefox-3.5.3/firefox

$ kill -9 1986
2. Killall Command – Kill processes by name

Instead of specifying a process by its PID, you can specify the name of the process. If more than one process runs with that name, all of them will be killed.
Example: Kill all the firefox processes

$ killall -9 firefox
3. Pkill Command – Send signal to the process based on its name

You can send signal to any process by specifying the full name or partial name. So there is no need for you to find out the PID of the process to send the signal.

Example: Send SIGTERM to all the process which has sample in its name.

$ pkill sample

How to debug your ssl certificate installation

If you're, like me, a hack who is always treading treacherous waters, who knows just enough server administration to destroy his own server, but so proud - or cheap - that you insist on doing it all yourself, you will eventually install a SSL certificate.

And you will eventually screw it up. I don't know why you did. I'm not sure how to fix it either. But, having screwed up enough times on my own, I know a few tricks that will solve most of the problems you have.

Hard and fast rules:

1. You are going to screw it up. Maybe you won't. Maybe you're going to meticulously follow the steps, checking your list twice like Santa. Congratulations. You are the 1%. For the other 99%, assume you're going to do something wrong, and move forward with that expectation.
2. Back up everything, everything, everything. Can you imagine the hell you will go through if you edit an apache conf file so hard that it bleeds, then breaks, and you have no record of what you changed? For god's sake, man, you aren't Linus Torvalds (which is actually a very good thing, because he's dead). 
3. Get your instructions in place. Your SSL issue will have them for you and, if you follow them slowly enough, you will probably have no trouble. But you won't, will you? Of course not. You're a server administrator and those instructions were meant for morons.

So now follow the installation steps, restart apache, then sit back annnnnd ...

...stare at the error screen on your browser. And then panic when all seven of your private blogs, spam sites, and failed startup attempts are now down because apache won't restart. 

What do you do? Here are some of the things I have done to eventually get me back on track:

1. Phone my systems admin friend and have him tell you what to do. But I guess that's not a practical approach. I don't want to spend too much time handing out his phone number. And he might get mad.
2. Is the SSL engine turned on? Of course it is. Why would I ask such a stupid question. I myself have never accidentally missed a configuration setting. And for that matter, there's no reason to check if you have told apache to listen on port 443, is there?
   
3. Type in

   # sudo apachectl configtest

   . Of course you ran this test before you restarted the server. Of course you didn't forget this one time. Just get over it and run configtest, and it will spit back any errors are you.
4. Turn on debugs in your conf file: LogLevel debug.
5. Compare your key and certificate. If they don't match up, you have installed wrong, and should just start again from scratch. The private key contains a series of numbers; two of those numbers make the "public key", and the others are part of the "private key". The "public key" bits are also found in your Certificate . Check that the public key in your cert matches the public portion of your private key:
   

   $ openssl x509 -noout -text -in server.crt
   $ openssl rsa -noout -text -in server.key
   

   
   Also try:
   

   
   $ openssl x509 -noout -modulus -in server.crt | openssl md5
   $ openssl rsa -noout -modulus -in server.key | openssl md5 
   

Uh, wait, what?

Some thoughts are better left unformed. Some insights are better left unsighted. Somewhere a nerd has earned his wings.