Reposting this.

It is apparent that Lucid is now leveraging CouchDB for use by most of the applications and settings. It also appeared that the details in CouchDB will also be included in synchronization should you enable Ubuntu One syncing.

Read more…

I was working on my laptop which dual boots between Ubuntu Jaunty and Windows XP when suddenly I found that the Fonts folder made my Windows XP to crash. This is how I fixed it.

People might think that this might be a sign of bigger problems to come. It ain’t. Windows is really like that - picky, bitchy, and naggish - like a bitter girlfriend that you haven’t made love with for a long time . Joking!

Well, there are really times that the Fonts folder contains a corrupted font, or you have unwittingly installed an “esoteric”, cool free font that you have downloaded from the net and that Windows is unable to ascertain just what that font is.

Well, the fix is really simple than most people think.

Windows XP (and even older versions) have a tool called System File Checker (sfc.exe). This little tool makes sure that your system files are of the correct and safe versions. However, there are times that Windows just “forgets” to use this tool to fix your problem. Well, you’re back to the rescue. Just run this command in the DOS terminal, or in Start | Run :

sfc /scannow

Make sure that you have your Windows XP install disc inserted in your optical drive because System File Checker will load the discs system files into the DLLCache and will compare and fix the existing installed files with those from the disc.

Doing this fixed my Font folder problem.

This might not fix everything that you might encounter, but this is a great tool to try with, in doing first level diagnostics and troubleshooting.

Good luck!

Technorati Tags: font, folder, crash, fix, system, file, checker, windows, xp

We were running Plesk on one of our servers, and Horde as webmail frontend for our users. The server has been running quite well for years on end and then suddenly users just couldn’t login to Horde. Even more mysterious is that no error message was displayed, and only a redirect back to the login page was done.

Checking the log at /var/log/psa-horde/psa-horde.log showed:

Jan 12 04:01:55 HORDE [error] [imp] FAILED LOGIN 123.234.22.123 (forwarded for [123.123.123.1]) to localhost:143[imap/notls] as user@ourdomain.com [on line 258 of "/usr/share/psa-horde/imp/lib/Auth/imp.php"]

We’ve tried using new and alternate user accounts to no avail. We tried checking and repairing the database tables in the Horde database. Rebooting the machine didn’t do squat.

What we didn’t do, which we should have done in the first place (and save more than 3 hours debugging), was to view the test page for Horde at http://ourdomain.com/horde/test.php and we were able to notice the line

session.auto_start disabled: No
Horde won't work with automatically started sessions, because it explicitly creates new session when necessary to protect against session fixations.

So we proceeded and edited the php.ini and set the following:

; Initialize session on request startup.
session.auto_start = 0

We then restarted httpd (/etc/init.d/httpd restart) and tried logging in to Horde, and it worked!

Our users can now login using Horde.

Enjoy!

Technorati Tags: Plesk, Horde, login, fail, maintenance, redirect, PHP, session, fix

Hello once again! First, I wanna apologize for the lack of updates (again). I have been so busy with new and exciting work and the possibilities and new skills have been really pouring in. Regardless, I wanna thank everyone for your continued support and finding this blog’s articles useful. My sincerest gratitudes. Anyways, I am sharing another really good solution for all of you guys out there.

Have you deployed Nagios and installed the NRPE plugin on your local and remote servers? Have you by any chance encountered, and was not quite able to solve, this error?

CHECK_NRPE: Socket timeout after 10 seconds

Actually this has also bugged our team a lot and we were really sure (or so we thought) that we have configured Nagios and the NRPE plugin correctly.

We thought it might be a problem with Nagios or the NRPE plugin and we haven’t been able to dedicate a lot of time to find out the problem due to other pressing tasks. But recently, I was able to find the time to diagnose the issue and now I am sharing with you the fix. And yes, it was really really straight forward and so damn simple! DOH!

On your remote machine, make sure that you have installed the NRPE plugin correctly. You can download the NRPE plugin documentation at http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf.

Once, you’ve configured your remote machine’s NRPE already, do local checking first.

# /usr/local/nagios/libexec/check_nrpe -H localhost
NRPE v2.8


If you get a response with a version of your NRPE, then you’re all set.

And do not forget to open port 5666 on your firewall (iptables or other wise). Refer to the NRPE documentation for more details.

On your monitoring machine, where Nagios was installed, install the NRPE plugin as well. Then do the remote NRPE check.

# /usr/local/nagios/libexec/check_nrpe -H
CHECK_NRPE: Socket timeout after 10 seconds.


Now, don’t be surprised if you get the CHECK_NRPE: Socket timeout error. We now need to make sure that our monitoring machine allows incoming and outgoing connections via port 5666.

To do just that, we open up our IPTables by doing:

# /sbin/iptables -A INPUT -s -p tcp -m tcp –dport 5666 -j ACCEPT
# /sbin/iptables -A OUTPUT -p tcp -m tcp –dport 5666 -j ACCEPT

The first command will allow our monitoring box to accept incoming connections from our remote_host via port 5666 and no other hosts and the second command will allow our remote machine to initiate connection via port 5666 to any remote machine. Of course we can make it tighter by specifying the destination box, but I don’t see the need for the meantime.

After adding the rules, make sure to save your new IPTables rules by doing

# /sbin/iptables-save > /etc/sysconfig/iptables

That’s it!

Try out some of these combinations to your remote host and see what the outputs are.

# /usr/local/nagios/libexec/check_nrpe -H -c check_load -t 120
#/usr/local/nagios/libexec/check_nrpe -H -c check_users
#/usr/local/nagios/libexec/check_nrpe -H -c check_zombie_procs

Enjoy!

Technorati linux, nagios, nrpe, monitoring
Site Search Tags: linux, nagios, nrpe, monitoring

I needed only one Apache HTTPD server visible over the Internet, and subdomains provided by internal webservers. I proceeded with mod_proxy.

On SLES10, go to /etc/apache2 and create a file named proxy.conf:

# Sample configs
# by hardwyrd
# 05/22/2009
#
# Disclaimer:
# Use at your own risk. It works for me, it might not work for you.
# If you decide to use or follow this config, you agree that I am not responsible for the damage
# to your system.

# Listen on internal interface only. Only mod_proxy uses this.

Listen 192.168.10.1:8080

# Set the user for mod_proxy
User nobody
Group nobody

# Turn on proxy requests
ProxyRequests On

Order deny,allow
Deny from all

# Declare your subdomain rechable from the internet.

Order deny,allow
Deny from all

# Allow only from specific IP addresses or allow all if this is accessible from the net.
Allow from all

# You can add as many
declarations as you can.

Create a virtual host on the public-facing Apache server. In SLES10, the config is at /etc/apache2/vhosts.d:

# Sample configs
# by hardwyrd
# 05/22/2009
#
# Disclaimer:
# Use at your own risk. It works for me, it might not work for you.
# If you decide to use or follow this config, you agree that I am not responsible for the damage
# to your system.

# A virtual host config is needed so that we can redirect the subdomain requests coming in at port 80 to the internal Apache server.
# Create equivalent virtual host entries for every
declaration in the proxy.conf .


ServerName your-subdomain.your-domain.tld
ServerAlias your-subdomain.your-domain.tld
ProxyPass / http://your-subdomain.your-domain.tld/
ProxyPassReverse / http://rspace.focusoutsourcing.com/


To enable the public Apache server forward the requests to the proper internal Apache server, you can use an internal DNS server with the correct A record for the domain pointing to the IP of the internal Apache server. Or, the quickest way is to add the subdomain to the hosts file (/etc/hosts).

#/etc/hosts
192.168.10.22 your-subdomain.your-domain.tld

On the internal Apache server, create a standard virtual host for the subdomain.

That’s it! Only one apache server will be visible to the public, and yet serve multiple subdomains, spread among various internal Apache servers.

Enjoy!

Technorati : apache, mod_proxy, web+server, linux
Site Search Tags: apache, mod_proxy, web+server, linux

Funny as it may seem, I fell for it (yet again perhaps?). I’ve installed CentOS5 on top of VirtualBox 2.2.2 on my Ubuntu Hardy 8.04 for the sole purpose of testing out ASP.NET hosting using Mono, XSP, and Apache. And I was in for a surprise that I could not access my virtual machine’s Apache web server instance.

I was able to install VirtualBox 2.2.2 vanilla (not the official Ubuntu package) without any problems. I followed it up by installing CentOS5 as a virtual machine. I then proceeded and configured the network interface for the virtual machine on the VirtualBox Management panel, and set it up to use “Bridged” networking.

I proceeded by booting the virtual machine and watched every boot message zip by without a hitch. I then logged into the virtual machine as root and configured the IP address for the network interface. After which, I pinged the IP address and got the reply I want. I then tried to log in via SSH, ang was able to get in. “Hmm… everything seems to be in order. Might as well continue.” I said to myself. Boy was I in for a surprise.

I proceeded and configured the web server, enabling name-based virtual hosting, started Apache and tried to browse the test page. And then… nothing! ACCKK!!! I checked the IPTables rules if there’s something a-miss. So far everything seems to be in order (really?) . Tried a couple more times, and still get a failure from Firefox. Hmmm.. what could it be. Pondering for hours what could have been missed. A colleague suggested to flush the entire set of IPTables rules, which I did and tried accessing the web server. What do you know! I was able to browse the basic landing page. “Hmmm.. there must be something wrong with the IPTables rules” I said whispering.

I proceeded and checked again /etc/sysconfig/iptables and sure enough, I found the culprit. I mistakenly added the IPTables rule that opens port 80 AFTER the reject rule! No wonder port 80 doesn’t open up. I edited the /etc/sysconfig/iptables again, and place the port 80 rule on top of the reject rule, which will then allow it to take effect first, before the reject rule is activated. And then everything worked as it should.

Lesson? Sometimes the obvious things are really hard to find and double checking definitely will prevent the unnecessary debugging for when your system goes to production. I’m just glad this is a simulation system and not production.

I think it was stupid of me not to notice the order of the rules in the iptables file. What do you think?

Technorati linux, virtualization, virtualbox, centos5, apache, webserver, iptables
Site Search Tags: linux, virtualization, virtualbox, centos5, apache, webserver, iptables

We needed a helpdesk and a knowledgebase system and we prefer that it be opensource. We have found OneOrZero HelpDesk and KnowledgeBase to be a good candidate. We decided to take a look at it and see for ourselves. Installation was tad easy. All you need is an Apache server, PHP, and MySQL and voila! We have been running it using MySQL for sometime but we didn’t as of yet let users use the system.

We have been mulling over the idea of integrating OneOrZero HelpDesk and KnowledgeBase authentication with our existing LDAP server which also authenticates our Windows domain users via our Samba PDC. OneOrZero is pretty much convenient for us since it already has LDAP authentication capability. Or so we thought.

Setting up LDAP for OneOrZero HelpDesk, required us to modify its settings. You can do this using its own control panel, by logging in as an administrator, or you can go brute it out by going to where the OneOrZero configuration files are located. In my case it is in

/srv/www/onezero/configuration/website_settings.php

Please note that the location may not be the same in your case, depending on where you extracted your files, and where your Apache DocumentRoot is located. Make the necessary adjustments.

After locating the file, make a copy first of the existing file (you dont want to lose working settings do you? then edit website_settings.php by opening your favorite text editor - which in my case is VI.

vi website_settings.php

Navigate your way down towards near the end of the file, and review the LDAP-related parameters. Please note, I’ll be using my own LDAP parameters as examples and yours might be different depending on your LDAP server flavor (AD, OpenLDAP, Netware/OES/others).

# Enable LDAP authentication. This is DB by default.
auth_method = "LDAP"

# IP address of your LDAP server
ldap_host = "192.168.10.10"

# If you are using AD, specify the domain name. I'm using OpenLDAP so, I ignored this.
ldap_domain = ""

# Specify the user that will be used to bind to your LDAP server. Not needed if anonymous bind is allowed
ldap_binddn = "cn=ldapbinder,dc=mydomain,dc=com"

# Specify the password for the binding user
ldap_bindpwd = "secret"

# Set the location in your LDAP schema where the search will start from. In my case, I have an OU called "Users"
ldap_rootdn = "ou=Users,dc=mydomain,dc=com"

# Provide here the search attributes. Note though that this might be different on your particular flavor of LDAP.
# Use an LDAP browser utility to double check.
ldap_searchattr = "uid"
ldap_fname = "givenname"
ldap_lname = "sn"
ldap_uname = "uid"
ldap_email_add = "mail"
ldap_office = "l"
ldap_phone = "telephonenumber"
ldap_context = "dn"


Save your file after editing.

We then tried logging in using our LDAP accounts, however it seems that OneOrZero cannot find our accounts, or rather LDAP cannot find the accounts passed by OneOrZero to it. So, I then looked at the LDAP log and checked what the problem is. Sure enough, I found the culprit.

Jan 14 11:18:15 x2100 slapd[4044]: conn=5857 op=1 SRCH base="ou=Users,dc=mydomain,dc=com" scope=2 deref=0 filter=”(uid=minime)”

No wonder LDAP cannot locate the user. Even though it is searching on the right section of the LDAP tree, it doesn’t know which one to pick up. Remember, we use our LDAP server as authentication for our Windows users via Samba as well. Heck, we even authenticate our SSH users via LDAP also.

Another challenge!

How do I hack the filter in OneOrZero so that it works for my LDAP server ? (GOD I LOVE THIS WORK!)

Simple, I have to locate the filter string deep in the vowels of OneOrZero’s source code and insert my own filter or manipulate it so that the output filter will meet what my LDAP server really needs.

OK OK! Enough suspense, how did I do it? Simple.

Navigate yourself to where you extracted OneOrZero - in my case /srv/www/onezero/common , and edit the file common.php . When you open the file, navigate yourself towards line 164 . There you will find the $filter variable which receives the value from the LDAP search attribute that was set in website_settings.php .

When you locate the $filter variable, comment the existing one, and replace it so that it looks like this:

// $filter = "($ldap_searchattr=$name)"; //This is the default filter string

$filter = "(&(objectClass=posixAccount)($ldap_searchattr=$name))" // This is my new filter string to fit my LDAP server.

Save the file and do a test login. That’s it!

If you still have trouble setting it up (which I doubt), feel free to look at the Administration guide at http://www.oneorzero.com/wiki/index.php?title=OneOrZero_Settings

Enjoy!

Technorati : oneorzero, helpdesk, linux, ldap, authentication
Site Search Tags: oneorzero, helpdesk, linux, ldap, authentication

You now have your nice PFSense firewall connected to the net and your users are happily connected then you decided to put up publicly-accessible network services like a web server. But horror starts to creep in when you found out that your users (or your developers) cannot access your public server using their workstations within your local network.

You tried everything in vain and suddenly felt the urge to scream with all your might.

AAAARRGGGHHH!!!!

As far as you’re concerned, you’ve setup PFSense correctly. You have enabled port forwarding quite perfectly. The web server is running without a hitch. You have your DNS working perfectly. But your users cannot seem to access your internal server using your public IP address or domain..

..then you raised your limp hands in resignation.

Dont despair. It’s really simple.

1. Open your PFSense web gui.

2. Move your mouse over to System, and click Advanced.

3. Scroll down, and look at the Disable NAT Reflection field. Make sure that it is unchecked.

4. Click on Save.

That’s all there is to it! Enjoy!

Technorati PFSense, NAT, reflection
Site Search Tags: PFSense, NAT, reflection