Question

Inconsistent results installing Squid Proxy server via "user_data" JSON POST command

I am writing an iPhone app in Swift to make proxy servers, using Squid.

Squid is being installed on a Cent OS VM, via Digital Ocean.

In the JSON I am “POSTing” to Digital Ocean, I am passing in a long string to the “user_data” parameter. This string is the full text of my YAML formatted #cloud-config file.

This is the text of my #cloud-config:


#cloud-config packages:

  • firewalld
  • squid
  • httpd-tools

write_files:

  • path: /etc/squid/squid.conf content: | auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/passwords auth_param basic realm proxy acl authenticated proxy_auth REQUIRED http_access allow authenticated http_port 3128

runcmd:

  • htpasswd -nb max abc123 >> /etc/squid/passwords
  • systemctl restart squid
  • echo “I FINISHED”

Above, the username is “max” and the password is “abc123”.

Sometimes this code works, and sometimes it fails. It seems to fail more often with more complex usernames or passwords, which doesn’t make sense to me.

Ultimately, once this is working consistently with a static username and password, I would like to be able to generate a random username and password, and add that to my Squid server, rather than the static “max” and “abc123” in the example code. I know how to do this in Swift on the client side, but not sure how to pass in these two variables. I tried building the string dynamically, but it was also inconsistent, so I wanted to this working FIRST with a static username and password.

Subscribe
Share

I ended up solving this by eliminating upper-case characters from usernames and passwords. This explains the behavior I was seeing with “more complex” passwords – which was simply my own testing – and coincidentally, hardcoding in test usernames and/or passwords that included uppercase letters.

I ended up encoding my user_data as a single long “bash script” string. However, I suspect my earlier “cloud-config” method would now work, since the elimination of the upper-case characters.


Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

This question was answered by @max0bb4b8e61624a91fd6a1228:

I ended up solving this by eliminating upper-case characters from usernames and passwords. This explains the behavior I was seeing with “more complex” passwords – which was simply my own testing – and coincidentally, hardcoding in test usernames and/or passwords that included uppercase letters.

I ended up encoding my user_data as a single long “bash script” string. However, I suspect my earlier “cloud-config” method would now work, since the elimination of the upper-case characters.

View the original comment