Friday, January 30, 2009
Net-SNMP and HP/UX B10.20
For some reason it took me a while to find pre-compiled binaries of Net-SNMP for HP/UX. This HOWTO is from Cacti but lists the locations of all Net-SNMP binary packages one could ever want. This includes AIX, Solaris and HP/UX. Enjoy!
Thursday, January 29, 2009
Solaris 10 and Net-SNMP
So I re-learned something about SNMP on Solaris today. I say re-learned since this is one of those things I always have to Google for and is precisely the raison d'etre for this blog. I re-learned how to turn off Sun's default SNMP daemon on Solaris 10 so I could start up the Net-SNMP daemon compiled for Solaris. Here's how:
/etc/init.d/init.sma stop
This stops and disables the System Management Agent as per this section in the Solaris System Management Agent Administration Guide on Sun's site.
With the default SNMP daemon dead and disabled, you can start up the Net-SNMP daemon using its own init script.
Enjoy!
/etc/init.d/init.sma stop
This stops and disables the System Management Agent as per this section in the Solaris System Management Agent Administration Guide on Sun's site.
With the default SNMP daemon dead and disabled, you can start up the Net-SNMP daemon using its own init script.
Enjoy!
Sunday, January 25, 2009
Comcast and the Battle of the SMTP
I got an email or three yesterday talking about how the new application I'd written wasn't sending out notification emails properly. Since I'd tested it out numerous times to ensure email wasn't going to be a problem from my end, I was a bit surprised. I figured it had something to do with bad data e.g. bad email addresses etc that was causing the problem.
After an email that I sent to my gmail account didn't show up even after 5 minutes, I decided to look at my mail server to see if it had recorded anything. I pulled up the admin console for my newly installed instance of Zimbra and saw about 400 deferred emails on the server status page. I was quite surprised that all those people hadn't complained. Regardless, I selected all the emails and re-queued them for delivery. Each and every one of them failed again. Errors ranged from connectivity errors to my ISP's mail relay (smtp.comcast.net) to other weird errors once my mail server connected to the relay host. Finally I tried my tried and true method - telnetting to port 25 on smtp.comcast.net and manually going through a mail session from helo to the final period. I couldn't even connect to port 25 on the mail relay server!
It turns out Comcast had recently removed access to port 25 on its mail relay server where "recently" refers to November 28th. I'm not entirely certain why I didn't see any issues even at the end of December and beginning of January when I launched the application. In any case, not only had they switched to using port 587 instead of 25, they were also requiring authentication using the username/password associated with your Comcast account to even send email via this relay.
Fair enough. Now to configure Zimbra to support an authenticated mail relay. Luckily I got help from the Zimbra Wiki. Following the instructions to the letter (except for substituting hostnames, usernames and passwords appropriately) I was able to get mail working again.
Now I just have to wait for 400 emails to get delivered 3 at a time - or whatever the absurdly low limit is for the Comcast mail relay.
After an email that I sent to my gmail account didn't show up even after 5 minutes, I decided to look at my mail server to see if it had recorded anything. I pulled up the admin console for my newly installed instance of Zimbra and saw about 400 deferred emails on the server status page. I was quite surprised that all those people hadn't complained. Regardless, I selected all the emails and re-queued them for delivery. Each and every one of them failed again. Errors ranged from connectivity errors to my ISP's mail relay (smtp.comcast.net) to other weird errors once my mail server connected to the relay host. Finally I tried my tried and true method - telnetting to port 25 on smtp.comcast.net and manually going through a mail session from helo to the final period. I couldn't even connect to port 25 on the mail relay server!
It turns out Comcast had recently removed access to port 25 on its mail relay server where "recently" refers to November 28th. I'm not entirely certain why I didn't see any issues even at the end of December and beginning of January when I launched the application. In any case, not only had they switched to using port 587 instead of 25, they were also requiring authentication using the username/password associated with your Comcast account to even send email via this relay.
Fair enough. Now to configure Zimbra to support an authenticated mail relay. Luckily I got help from the Zimbra Wiki. Following the instructions to the letter (except for substituting hostnames, usernames and passwords appropriately) I was able to get mail working again.
Now I just have to wait for 400 emails to get delivered 3 at a time - or whatever the absurdly low limit is for the Comcast mail relay.
Friday, January 16, 2009
Paypal IPN and mc_fee
I encountered an interesting problem today with accepting payments for an online registration solution I wrote for a non-profit organization. The application accepts payments using Paypal's Instant Payment Notification feature. IPN works as follows:
- You put a form (hidden or with bits visible) that POSTs data to Paypal
- This brings the user to Paypal where they can pay using either a credit card or their Paypal account
- As part of processing the user's payment, Paypal takes key information about the user's payment e.g. transaction id, amount, and other sundry details and POSTs them to a custom instant payment notification URL (as it happens to be called) on your site
- This URL is hopefully hosts a script or other form of code that can pick up all the POSTed IPN variables and POSTs back the information with one extra variable to validate the information
- Once this POST back to Paypal returns with a success status the application can record the user's payment and credit them appropriately.
Labels:
application,
IPN,
online,
payment,
Paypal,
problem,
programming,
web
Tuesday, January 13, 2009
Recovering Virtual Machine Templates after Re-Installing VMware Virtual Center
If you have ESX servers managed by VMware Virtual Center chances are you've created templates of standard types of machines so deploying a new one becomes simpler. These templates are such time-savers that I tend to keep tweaking them with every new requirement until I have the perfect pristine CentOS or Win2k3 or FreeBSD host. Deploying a new virtual machine from a template is a cinch and the deployed machines always look identical - at least until you start customizing them. This means you can create scripts that run against a truly standard configuration and know that it will work the same way every time but I digress. This post is about what happens when you have to re-install VMware Virtual Center. This is something that I found two solutions for which both work well. However, the second solution is far simpler and less time-consuming.
The Easy Way
The first solution relies on the ability of VMware Infrastructure Client to convert a Template into a Virtual Machine and back. Since all virtual machines stored on ESX servers managed by a new instance of Virtual Center are automatically recognized and properly populated in the Virtual Infrastrucure Client, make sure you name every template to reflect that it's a template by e.g. putting the word "Template" somewhere in its name, etc.
The Elegant Way
This method doesn't require you to convert your templates to virtual machines and back. Just re-install your instance of Virtual Center and you will notice all your templates disappear the next time you connect to the new Virtual Center using your Virtual Infrastructure Client. Follow these steps to bring them back:
The Easy Way
The first solution relies on the ability of VMware Infrastructure Client to convert a Template into a Virtual Machine and back. Since all virtual machines stored on ESX servers managed by a new instance of Virtual Center are automatically recognized and properly populated in the Virtual Infrastrucure Client, make sure you name every template to reflect that it's a template by e.g. putting the word "Template" somewhere in its name, etc.
- Switch your Virtual Infrastructure Client to display both virtual machines and templates by using the keyboard shortcut Ctrl-Shift-V or by clicking on dropdown associated with the large "Inventory" drop down in the top toolbar and choosing "Virtual Machines and Templates".
- Right-click on each template and choose "Convert to Virtual Machine".
- Once you've converted all your templates to virtual machines you can re-install Virtual Center.
- Now re-connect to the new instance of Virtual Center and you'll see all your templates as virtual machines.
- Right-click on each virtual machine that used to be a template (see where the naming comes in?) and click on "Convert to Template"
The Elegant Way
This method doesn't require you to convert your templates to virtual machines and back. Just re-install your instance of Virtual Center and you will notice all your templates disappear the next time you connect to the new Virtual Center using your Virtual Infrastructure Client. Follow these steps to bring them back:
- Switch your Virtual Infrastructure Client to display your datastores by using the keyboard shortcut Ctrl-Shift-D or by clicking on dropdown associated with the large "Inventory" drop down in the top toolbar and choosing "Datastores".
- Click on a group and then a datastore and in the right detail panel click on "Browse Datastore...". This should bring up a window that will allow you to browse that datastore. Each virtual machine and template will have its own directory in this datastore.
- Click on a directory named after one of your templates. The right panel will change to show you all the files in that directory.
- Right click on the only file of type "Template VM" and click on "Add to Inventory".
- In the dialog box that pops up, give the template a name (presumably the same name as it currently has) and choose its location (presumably the same group it's in now).
- In the next dialog box choose the host to store the template on. This should be the same ESX server whose datastore you're browsing.
- After validating the template/vm it will present the last dialog of the wizard with the details of your "VM". Click "Finish" and you're done.
- Close the data store browser and change your Virtual Infrastructure Client to "Virtual Machines and Templates" mode using Ctrl-Shift-V or by clicking on Inventory and choosing "Virtual Machines and Templates" and you'll see the template back in the inventory!
Labels:
howto,
template,
virtual center,
virtual machine,
vmware
Friday, January 9, 2009
Upgrading from Plone 2.0.4 to 3.1.6
So here's my dilemma. I have a site running on Zope 2.7 and Plone 2.0.4 that I need to migrate to Zope 2.10 and Plone 3.1.6. I'm replacing the server that the site is running on with a newer server and decided to go with CentOS 5 as the OS of choice instead of the Gentoo that was running on the original server. After adding a few repositories e.g. CentOS Plus, EPEL and RPMForge I had access to a Zope and Plone RPM. Normally I would either build the same version I had on the original server or find an RPM of the same version. However, this time I decided to just upgrade everything and hopefully start keeping up with newer versions as they come around .
It turns out that upgrading isn't as simple as copying your Data.fs file to a new Zope instance running the latest versions of Zope and Plone. Go figure :) After much trying then getting frustrated and searching I came across this blog where the author seems to have come to the same conclusion as I did: the only way to do the upgrade I desired was to upgrade Zope and Plone in lockstep. This means I'll have to upgrade Plone to 2.1, then Zope to 2.8, then Plone to 2.5, then Zope to 2.9, etc.
Luckily the Plone site has good documentation about the incremental upgrades and the whole process should be possible. Now all I have to do is go through the incremental upgrades on a virtual machine so I end up with a more-or-less pristine copy of the site for deployment on the new server.
It turns out that upgrading isn't as simple as copying your Data.fs file to a new Zope instance running the latest versions of Zope and Plone. Go figure :) After much trying then getting frustrated and searching I came across this blog where the author seems to have come to the same conclusion as I did: the only way to do the upgrade I desired was to upgrade Zope and Plone in lockstep. This means I'll have to upgrade Plone to 2.1, then Zope to 2.8, then Plone to 2.5, then Zope to 2.9, etc.
Luckily the Plone site has good documentation about the incremental upgrades and the whole process should be possible. Now all I have to do is go through the incremental upgrades on a virtual machine so I end up with a more-or-less pristine copy of the site for deployment on the new server.
Wednesday, January 7, 2009
About this blog
I've tried blogging before mainly using one as a daily diary of sorts. I have never followed through with it. However the idea of this blog is something that has been ruminating in my mind for a while and I'm finally doing something about it.
The idea is to have a semi-irregular (is that a word?) blog where I can record things I've learned in my profession of choice: IT, software engineering or "computers". I can then search my own blog to find solutions to problems I've encountered in the past. One possible side-effect of a blog such as this would also be that future employers can read through it to get a feeling for what I've done in the past; of course depending on the kinds of problems I've successfully solved that could be a bad thing too :)
In any case, I'm just kicking this blog off so I have some place for a brain dump when I need to. If you're not me, you're probably lost :) If you're not lost then welcome!
The idea is to have a semi-irregular (is that a word?) blog where I can record things I've learned in my profession of choice: IT, software engineering or "computers". I can then search my own blog to find solutions to problems I've encountered in the past. One possible side-effect of a blog such as this would also be that future employers can read through it to get a feeling for what I've done in the past; of course depending on the kinds of problems I've successfully solved that could be a bad thing too :)
In any case, I'm just kicking this blog off so I have some place for a brain dump when I need to. If you're not me, you're probably lost :) If you're not lost then welcome!
Subscribe to:
Posts (Atom)