Openstack Swift with swauth: Account creation failed: 400 Bad Request, User creation failed: 400 Bad Request

Getting another issue when creating an account via swauth,


root@proxy:~/s3-curl# swauth-add-user -A https://127.0.0.1:8080/auth/v1 -K swauthkey -a system testuser testpassword
Account creation failed: 400 Bad Request
User creation failed: 400 Bad Request

So, again, I tried to google and see what can I do with this error, unfortunately seems not much could be done until I notice that it is the Admin URL causing the issue again. So I changed the Admin URI from /auth/v1 to /auth/ and see how it goes


root@proxy:~/s3-curl# swauth-add-user -A https://127.0.0.1:8080/auth/ -K swauthkey -a system testuser testpassword
root@proxy:~/s3-curl# swauth-list -A https://127.0.0.1:8080/auth/ -K swauthkey system
{"services": {"storage": {"default": "localhost", "localhost": "https://127.0.0.1:8080/v1/AUTH_e4afb2e7-d77f-4c7a-a431-01490ba5e982"}}, "account_id": "AUTH_e4afb2e7-d77f-4c7a-a431-01490ba5e982", "users": [{"name": "testuser"}]}


So it looks the issue is fixed.

Openstack Swift with swauth, getting "Account creation failed: 500 Server Error" when adding account

During testing of Swift with swauth, I was trying to add account to swauth database with swauth-add-account but it was failed out with "Account creation failed: 500 Server Error"

root@proxy:~# swauth-add-account -A https://1.2.3.4:8080/auth -K swauthkey testgp
Account creation failed: 500 Server Error


With further checking, it looks like "allow_account_management = true" have to be added under [app:proxy-server] tag of proxy-server.conf like this.






[app:proxy-server]
use = egg:swift#proxy
allow_account_management = true
account_autocreate = true
Once above line is added to configuration file, followed by proxy restart and that should fix the problem.

root@proxy:~s3-curl# swauth-add-account -A https://1.2.3.4:8080/auth -K swauthkey testgp
root@proxy:~s3-curl# swauth-list -A https://1.2.3.4:8080/auth -K swauthkey
{"accounts": [{"name": "system"}, {"name": "testgp"}]}

ForwardX11 option in ssh_config

To allow ssh client to enable X11 Forwarding always, one can add option "ForwardX11 yes" to /etc/ssh/ssh_config or its own ssh_config under home.

# grep "ForwardX11 yes" /etc/ssh/ssh_config
ForwardX11 yes
 
One may also know that we can tell the ssh client to turn on X11 forwarding from ssh cli via -X or -Y option.

e.g # ssh -X user@1.2.3.4

So, if we have "ForwardX11 yes" be set on ssh_config, all ssh sessions initiated by your machine will be have option "-X" be enabled. However, in some situation you may want to disable this feature and you have no access to /etc/ssh/ssh_config, you can

# ssh -o ForwardX11=no user@1.2.3.4

And then it would stop doing X11 forwarding for that ssh session.

OpenStack Swift with swauth, Auth subsystem prep failed: 400 Bad Request

Was mudding around with Openstack Swift recently and found that there are quite a lot of issue to get it working.

One issue I come across today is the inability to run swauth-prep to set up the account environment on my swift-proxy (version 1.4.6).

root@proxy ~/s3-curl# swauth-prep  -A https://127.0.0.1:8080/auth/v1 -K swauthkey
Auth subsystem prep failed: 400 Bad Request

Keep googling but dont have much finding. When I was stucked, i keep reading their online forum and then I come across an article saying the correct URL for swauth-prep should be on /auth/ instead of /auth/v1. So I changed the admin URL to

root@proxy:~/s3-curl# swauth-prep  -A https://127.0.0.1:8080/auth/ -K swauthkey
root@proxy:~/s3-curl# swauth-list -A https://127.0.0.1:8080/auth/ -K swauthkey
{"accounts": [{"name": "system"}]}

And then viola, it works.


** BTW ** Chances that it is either swift storage permission problem or it is indicating a connection problem between swauth and swift nodes.

Below syslog error would indicate a connection issue between swauth node and swift storage nodes.

May  3 00:07:47 swift-proxy swift ERROR with Account server 192.168.0.11:6002/vdb1 re: Trying to PUT /AUTH_.auth: Connection refused
May  3 00:07:47 swift-proxy swift ERROR with Account server 192.168.0.12:6002/vdb1 re: Trying to PUT /AUTH_.auth: Connection refused
May  3 00:07:47 swift-proxy swift ERROR with Account server 192.168.0.13:6002/vdb1 re: Trying to PUT /AUTH_.auth: Connection refused
May  3 00:07:47 swift-proxy swift Account PUT returning 503 for (503, 503, 503) (txn: tx79ff210a2f5249989abecb8319a64126)

In above scenario, I checked my configuration and found that there is a discrepancy on port settings between rings file and swift node configuration files (object-server.conf / account-server.conf / container-server.conf)

AWS storage gateway port 80 connection refused

Was testing on AWS storage gateway services in my ESXi host.  So what is AWS storage gateway? Basically it is a AWS service to host behind your on-premise firewall. An AWS customized VM living on ESXi will be put on-premise and allow remote storage management from AWS console. The VM on ESXi will present storage via iscsi which allow remote read-write access..

I was following this documents but unfortunately I jump into the condition while I was trying to activate my storage gateway VM. It looks like activation require access on port 80 but unfortunately I see nothing on port 80. Running nmap against the VM but I see nothing coming up.


root@localhost:~$ nmap -sT 1.2.3.4


Starting Nmap 5.00 ( http://nmap.org ) at 2012-03-29 16:13 HKT
Interesting ports on 1.2.3.4:
Not shown: 996 filtered ports
PORT     STATE  SERVICE
22/tcp   closed ssh
80/tcp   closed http
631/tcp  closed ipp
3260/tcp closed iscsi

 I tried to get into the storage VM as root (prior to the that, I booted the VM to single user mode and reset the password, for details see here) and found that no services are running on those ports.

With further checking, it seems that it have to do with the time service on the VM. The storage VM will need an very accurate time or otherwise it will not be coming up. As per the suggestion from setup guide, I enabled ntp service on ESXi and then enable the "Synchronize guest time with host" option on VM followed by VM restart. I hope it would work but somehow it doesnt, looks like time didnt catch up still.

Turn out I manually setup the time by logging into the storage gateway VM and set it up. After that I proceed with VM restart and then port 80 is coming up. Now I could activate the VM gateway.

Reset root password for AWS Storage Gateway VM

I am not sure if that would violate the terms and conditions of using AWS Storage Gateway VM, what I know is that the default sguser is pretty restrictive and not much troubleshoot could be done from that user (well, I kept seeing activation failure when tried to activate the Storage Gateway service and it looks like port 80 was rejecting the requests for some reasons).

So, as a last resort I tried to "break in" the VM by booting it into single user mode so that I could reset the password there (thanks God, as long as it is still a general Linux).

To reset the password, hit "e" at the Grub menu, use the up-down cursor to scroll to the line start with "Kernel". Once you are on that line, press "e" and then append "boot single" to the end of the line and press enter and "b" to boot. After that the VM will be booted to single user mode and you could simply type "password root" to reset the root password.

So what makes it good to reset the root password? You could get into this VM and do further troubleshooting. In my case, I get into the AWS Storage Gateway VM and found that port 80 didnt come up at all for some reason so that I could check on something else.(though, with further investigation, it looks like i didnt configure proper ntp options for the VM and ESX host)

Tricks to avoid DHCP client to override /etc/resolv.conf

I have a laptop installed with Ubuntu and is using DHCP client to connect to the Internet in couples of locations. Most of the DHCP server love to offer DHCP IP bundled with DNS addresses which is kind of convenience if one dont have their own DNS. For some reason, I have to use my own DNS server to perform DNS lookup and this DHCP kindness is getting annoying as I have to update the resolv.conf everytime I got the DHCP IP.

Just think of a trick to lock the /etc/resolv.conf from overwriting by doing chattr +i, i.e.

[root@ ~]# lsattr /etc/resolv.conf
------------- /etc/resolv.conf
[root@ ~]# chattr +i /etc/resolv.conf
[root@ ~]# lsattr /etc/resolv.conf
----i-------- /etc/resolv.conf

After that the file /etc/resolv.conf would be locked from writing until removal of this tag. I tested it by appending some crap to the /etc/resolv.conf but it doesnt allow me to write over.

[root@ ~]# echo some-crap >> /etc/resolv.conf
-bash: /etc/resolv.conf: Permission denied

Now I could keep using my own DNS and no need to update the file all the time.

Falling back is easy.

[root@ ~]# chattr -i /etc/resolv.conf
[root@ ~]# lsattr /etc/resolv.conf
------------- /etc/resolv.conf