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

October 5, 2019 106 views
Automated Setups Deployment

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: | authparam basic program /usr/lib64/squid/basicncsaauth /etc/squid/passwords authparam basic realm proxy acl authenticated proxyauth REQUIRED httpaccess 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.

1 comment
  • 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.

1 Answer

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

Have another answer? Share your knowledge.