fernandes.io

This week I was trying to get an RHEL system to authenticate me using my Active Directory credentials. After a bit of looking around, I cam across this wonderful step-by-step procedure to get it done: Attaching a RHEL6 server install to Active Directory for authentication Everything was going on well. I was able to do a local login using: ssh myuser@MYDOMAIN@localhost I just thought it might be cool to try logging in to my newly configured ADS authenticated box over SSH from another machine. So I tried, ssh myuser@MYDOMAIN@192.168.0.1 which obviously didn't work. The shell was treating "MYDOMAIN@192.168.0.1" as the hostname. With a little bit of playing around I found out that the following worked: ssh "MYDOMAIN\myuser"@192.168.0.1 It looks like specifying the domain the way usually Windows expects it really did work if it was enclosed in quotes!

I had a setup of tomcat running on port 8080 and Apache proxying for tomcat on port 80. If I tried to access webapps directly from tomcat on port 8080,. they were accessible, while on port 80, I would get the followig error: Proxy Error 502 “Reason: Error reading from remote server” with Apache 2.2.3 following fix worked: adding retry=1 acquire=3000 timeout=600 Keepalive=On after the Proxy directive in the http configuration.

My aim was to allow a couple of colleagues to ssh into my shared hosting server at GoDaddy. If it was any other server, I could have very well created another user which could be used by anyone else who needs access to the server. But, on GoDaddy shared hosting servers you get just one ssh user, hence this blog entry. As described in Max Beatty's  blog , its a very simple job. But my approach was a little different, I did not want to keep copying everyone's public key into my godaddy server's .ssh/authorized_keys2 file. Instead of that, I created a new public/private key pair [ausmarton@ausmarton ~]$ ssh-keygen Next, step which is similar to Max's approach is to copy the newly generated public key onto our server. [ausmarton@ausmarton ~]$ scp ~/.ssh/id_rsa.pub user@remote-host:.ssh/authorized_keys2 If you're on a linux system, you can use ssh-copy-id, which does it quite neatly. [ausmarton@ausmarton ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host Now, you just need...

By default, CouchDb is configured to be access only from a local port, i.e: you can connect to a couchdb instance as long as it is on the same host. Also, it is necessary that the HTTP request be made using the loopback IP address (127.0.0.1). In case you want to be able to access a couchdb instance from an external machine, you need to make some changes to the couchdb configuration. Note that you would need to have superuser access in order to make changes to these files. Usually couchdb will have two configuration (ini) files in /etc/couchdb depending on your installation. Both these files (default.ini and local.ini) can be used to enable remote hosts to access couchdb. The configuration required for this is: [httpd] port = 5984 bind_address = 0.0.0.0 By default the configuration would be: [httpd] port = 5984 bind_address = 127.0.0.1 This means that the Http server is bound only to the loopback IP address, which is why we change it to 0.0.0.0 to make it bind to any IP address. If...