Question

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

Posted October 5, 2019 506 views
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.

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.

×
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

Submit an Answer