This post is pretty straight forward but I want to mention there is a trick you have to use in Debian to get everything working correctly after you have all your SNMP packages installed. I didn’t realize this when I was setting this up the other day and it tripped me up for awhile.
So to start things off, we need SNMP and SNMPD on our systems.
sudo aptitude install snmp snmpd
We also need to update our SNMP settings to reflect the read only SNMP community string that we want to use. The default is public but it has been criticized for being susceptible to security breaches so you should probably keep that in mind when setting up SNMP in your environment.
At the very minimum your snmpd.conf file should look something like the following:
rocommunity mysnmpstring
Once you have updated this you need to unbind your localhost so that it can be read by others on the network. This is what tripped me up initially on my Debian box, I do not believe it is an issue in Ubuntu but if it is then you should be able to use these instructions as well. To fix this problem you need to edit the /etc/default/snmpd file and chop off the 127.0.0.1 from the SNMPDOPTS section. When it is fixed it should look like this:
You can check your handy work when you are done to make sure everything is working correctly by using this command from either the local host or another machine with SNMP installed on it.
snmpwalk -v1 -cpublic HOSTNAME/IP
Hopefully this will save time for somebody in the future, it certainly tricked me.
If you have been a follower this blog, I wrote a post awhile back that described my preferred settings in tmux and just recently wrote a post about getting set up with bitlbee. Today we will be adding on another piece to what I will be calling my ultimate command line theme by introducing another useful command line tool for communications called Irssi. Here are the back posts to these if you missed them.
Now that we have that out of the way let’s talk about Irssi. Irssi is a console based IRC client that has been around for quite a while now. There is somewhat of a debate holy war as to which console based IRC client is the best. There are a number of hardcore Irssi users around that tout it is as the best, with the likewise being true for Weechat fans. Before going any further I will say that there is definitely a certain amount of leg work to get Irssi up and running with the full set of customizations and features. That said, I believe the extra work is worth every minute of time and effort if you are looking for a fully featured, rich IRC experience.
I want to present both of these clients (Irssi and Weechat) to readers and let each person decide for themselves which is the best, because saying one is better than the other wouldn’t be a fair comparison, and is really like comparing apples and orages. With that said, in a future post I will be going over the basics of using Weechat, the other touted console based IRC client.
Here we will assume that you have created and set up a user with irc.freenode.net. Once that step has been completed you should be able to follow these instructions without any issues.
You may have to shutdown and restart Irssi at this point for it to recognize the network name “freenode” in the next step.
/CHANNEL ADD -auto ##/r/sysadmin freenode
Adding advanced_windowlist.pl
First we need to download the script and put it into the appropriate place. If you haven’t created your Irssi scripts directory and your autorun directory go ahead and make them quickly.
Change directories to your scripts directory and download the script.
cd ~/.irssi/scripts
wget http://anti.teamidiot.de/static/nei/*/Code/Irssi/adv_windowlist.pl
Let’s quickly set it to be executable.
sudo chmod +x adv_windowlist.pl
Now we need to symlink this script and then run it in Irssi. To symlink it run the following,
cd ~/.irssi/scripts/autorun
ln -s ../adv_windowlist.pl
And finally to load it into Irrsi.
/run adv_windowlist.pl
That should be it. This can come in handy when you have any more than a handful of windows and can’t keep your conversations straight. If we take a look at our Irssi session we can see that there is a name associated with each window number now.
As you can see there is now a name associated with each of the windows that we have open. This looks pretty good but there are some cool features in this script that we are going to leverage to make it look even better. In your Irssi session run the following commands to customize your display even further,
OK, this is looking better. We now have our current conversation underlined, our windows named and numbered with decent formatting and have set windows with activity to update and change colors. There are more options if you look at the script itself but this is a pretty good start.
Setting up hilight.pl
This script will add in the ability to check messages that contain your nick. This is a good way to easily check messages while you were away or didn’t get a chance to respond to. First we need to make sure that the new window will split correctly.
SET autostick_split_windows ON
/hilight <nickname>
Now we add in and configure our new notification window.
/window new split
/window name hilight
/window size 4
Set up nm.pl
The description from its creator is “right aligned nicks depending on longest nick”. This script will help with the readability and organization of your different chats. I’m not sure if it requires nickcolor.pl but I have it in my scripts folder and symlinked to my autorun folder just in case. Just load nm.pl in like you do for all other scripts and it will start doing its things.
/run nm.pl
Setting up themes
Definitely not a necessity but can help to make things cleaner and easier to read. So far I have played around with the xchat and fear2 themes but will come back and update this post if I happen to find a better theme. The good thing is that thems are really easy to set up and use. So to load a specific theme just copy it into your /.irssi directory and turn it on in Irssi.
That’s all I have on Irssi for now. If there is one complaint that I have about Irssi it is that the nicklist.pl script doesn’t play nicely in tmux (however it should be fine in screen). It is a manual process and is a pain in the ass to get set up so I have chosen not to cover it in this post. It is possible I know, but for me, it just wasn’t worth the trouble. If you know of an easy way to get this working inside of tmux let me know.
Bitlbee is a way to bridge IM and IRC together essentially allowing you to connect to your IM network through an IRC interface. One great feature of Bitlbee is that it supports a large number of different protocols (including Gtalk, Yahoo!, Facebook and Twitter), which happen to be nearly all the major platforms I’m concerned with, excluding Microsoft Lync. The main reason I want to discuss Bitlbee now, ahead of time, is because I will be doing a series of posts that specifically tie Bitlbee in with a few of the more popular IRC clients.
As you will see, there are slight differences in how Bitlbee behaves inside each of the IRC clients I have been trying out, I will leave these details out for now to make things easier to follow. Today’s post will be more guided towards general use of Bitlbee, so I will be going over things like how to get around and its basic usage.
As usual, I will be running in Ubuntu so these instructions are specific to Debian based distros. Outside of installation, I image the usage will be very similar in other distributions because most of the commands and configuration are happening inside Bitblee.
Getting used to Bitlbee
Let’s start off by getting Bitlbee installed.
sudo aptitude install bitlbee
Now let’s go ahead and add in our gtalk (jabber) account.
Optional – turn on oauth (Still having some issues with this one).
account gtalk set oauth true
oauth = 'true'
Log in to Gtalk.
account jabber on
Start a chat in a new window.
/msg NickName Hello!
Getting a listing of various IM accounts.
account list
account list online
account list all
Managing various IM contacts, pretty self explanatory. Here 0 is the gtalk account we added earlier, [email protected] is the person we are adding to our account and nickname is how they will show up in our contact list.
If you ever need to know if a specific package or a specific piece of software has been installed on a Debian system there are a variety of ways to tell, as you are probably aware of. One way that recently caught my eye, which is fast and easy to check from the command line is the search feature of aptitude.
Now, without speaking on the merits of using aptitude for package management (this is an entirely different topic) I would just like to mention here that it (aptitude) needs to be installed for this method to work. If you don’t have it installed already, it’s super simple.
sudo apt-get install aptitude
Okay, with that piece in place we just need to check that the package we are looking for is installed. So to do that, enter the following command.
aptitude search '~i' | less
Basically, this command will output a list of installed packages. I just added the | less to easily be able to scroll through the packages. In my opinion, the flexibility and usefulness of the search feature on its own is probably enough to start using aptitude, although this can be done similarly with apt-get. You may notice an “A” next to a number of these installed packages. This indicates that a package was automatically installed.
If you take a look at the output from this command it will look similar to the example posted below.
As I said, this is a quick and dirty way to view installed packages, but there are definitely other ways to go about this. I was unaware of the search functionality and well, I like aptitude so I thought that I would share the knowledge. Let me know if you know of any other cool and/or easy ways to check for installed packages.
Forgive the boring title for this post but I do think that this is a really important topic and one that I had to deal with recently at work. Somehow one of our Exchange mailbox databases became corrupted and one of our users lost a ton of email, which, I’m almost 100% sure was related to the outage catastrophe we experienced 1.5 weeks ago. This event made me thank the Flying Spaghetti Monster that I was getting good backups from our (sometimes shaky) backup solution, Data Protector. Anyway, for this topic I will just assume that you are getting backups from whatever backup solution but it isn’t all that important because the majority of this post will cover specific instructions for the procedure within Exchange, so you can take bits and pieces and apply them where you need to.
Before I go any further, it is always worth mentioning; make sure you are getting good backups!
Ok, now that we have that out of the way I will show you the basic restore procedure within the Data Protector environment. Select the Restore option from the drop down list -> MS Exchange 2010 Server.
Then select the source to backup up (Whichever database that needs to be restored). With in Data Protector specify the restore options that you would like.
These are the options I used most recently.
Restore method: Restores files to temporary location
Backup version: Whichever data you decide you need to roll back to
Restore chain: Restore only this backup
Target client: Select the mailbox server that you want to restore to
Restore into location: This can be any location, just make sure there is enough disk space.
Select Restore databse file only
Once you have chosen your restore options, click the restore button to begin the restore procedure.
Once the database has been restored with Data Protector
Now for the fun stuff. This is the part that I’m guessing most will probably be concerned with, but I didn’t want to leave out my Data Protector peeps. Open up an Exchange Management Shell on the mailbox server that you restored your database to. Technically it can be from any server as long as you connect to the correct mailbox server I guess. Anyway, rename your restored database to something like “recoverydb.edb”. Change directories into the restore folder, then check the status of the newly restored database with the following command:
eseutil /mh recoverydb.edb
You should see something similar to the following:
If it shows Clean Shutdown you can skip ahead. Since we didn’t bring any log files down with us in this restore we will need to run the database hard repair on this database using the following command:
eseutil /p recoverydb.edb
After running the repair you should get a clean shutdown state if you check again (eseutil /mh).
Now we need to create a recovery database for Exchange to use in order to recover this data from.
It is important that when you create your recovery database it matches the renamed .edb file. So since I renamed my recovery database to recoverydb.edb, I used recoverydb in the Powershell command. If you want to check to make sure this step was done properly, use the following command to verify that the database is roughly the size you are expecting it to be:
After everything looks good we mount our database.
Mount-Database recoverydb
Just to verify that the database has stuff in it and we can find the person we’re looking for, we will take a quick look at the database contents, as shown below.
Get-MailboxStatistics -Database recoverydb
It looks like there are users there so all we need to do now is dump their emails into a temporary/recovery account in Exchange with the following command:
-RecoveryMailbox is the user mailbox that we are pulling data from, the source mailbox
-Identity is the user mailbox that we are putting data into, the destination mailbox
-RecoveryDatabase is our newly created recoverydb
-TargetFolder is the a folder that we will create on the target user to house the recovered items
-Verbose optional debugging information if there is a problem anywhere in the process
The wording and syntax of this command is a little bit tricky. Just remember that the -RecoveryMailbox signifies the backup location and the -Identity signifies the restore location. After this process completes (could take awhile depending on the mailbox size) you should be able to log in to the temporary account and take a look at the newly created “RecoveredItems” folder in which the mailbox contents of the user mailbox we are restoring have been copied in to.
Once this is done, just right click the target mailbox (temporary_account), click Manage Full Access Permission and give the restore mailbox (user_to_recover) full permissions through the Exchange Console so you can copy over messages, etc. in Outlook.
This step can be done any number of different ways but I chose this method because I was more concerned about the safest way to do this. You could, for example, copy the contents directly into the user mailbox if you wanted. Another option would be to export the contents of the temporary user out into a .pst file, with something like the following:
That should be it, after you are done and the emails have all been recovered , be sure to dismount the recovery database and delete the files to free space back up on your mailbox server.
