# Server Management H3 --- ___ This is a report for the Configuration Management Systems course taught by [Tero Karvinen] [Tero Karvinen]: http://terokarvinen.com/2020/configuration-management-systems-palvelinten-hallinta-ict4tn022-autumn-2020/ Date: 15-11-2020 This report is written completely in markdown. As a guide for the syntax i used [this cheatsheet.](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) Ill leave a link to the actual .md file [over here.](/static/markdown.md) I was reading [this book](https://www.packtpub.com/product/learning-saltstack-second-edition/9781785881909) on O'reilly learning and in chapter 6 i learned that salt supports having salt-states in a git repository natively. From what i understand it should be done by changing a few things in the salt-master config. I did look at [this documentation](https://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html) for this task as well. Before i tried configuring salt to use a git repository i did a few other things. I started by creating a git repository on github and cloned it to my master with the following command. git pull https://github.com/heiskane/salt-states.git I added a simple state to add a file to the slave and with the following commands added it to my repository. git add . git commit -m 'hello world' git push Note that i already have set my email and username for git so i didnt need to do it here. Before moving on i looked at the output of `git log --patch` (after adding something more and pushing it). This will show all the changes made to the repository as seen below ![git log --patch](/static/img/server_management/h1_045.png "git log") To show the usecase for `git diff` i added some more text in `hello.txt` and ran the command. ![git diff](/static/img/server_management/h1_046.png "git diff") Finally i ran the `git blame` command on the `hello.txt` file. ![git blame](/static/img/server_management/h1_047.png "git blame") This shows when each line in the file was modified and by whom. I pushed the changes i made before moving on. To do a **stupid** change to the repository i ran `head /dev/urandom >> hello.txt`. To revert changes and go to the previous version i ran `git reset --hard`. As seen in the following image the change i did was reverted and i have returned to the *working* version. At this point i wanted to configure salt to use my git repository so i edited my configuration file at `/etc/salt/master`. I added the following lines: fileserver_backend: - gitfs gitfs_remotes: - https://github.com/heiskane/salt-states.git After doing these changes i restarted salt master with the following command. sudo systemctl restart salt-master.service I tried applying the state but got a bunch of errors. ![hello not found](/static/img/server_management/h1_048.png "hello not found") Atfer a while of googling i remembered that salt uses the `master` branch as the `base` environment but because i created a repository on GitHub my `master` branch is actually called `main`. I realized this while lookin at [this article](https://www.roylarsen.xyz/saltstack-gitfs/). I tried adding the following configuration: gitfs_remotes: - https://github.com/heiskane/salt-states.git - saltenv: - base: - ref: main I restarted salt-master but this gave me a bunch of errors. Atleast now i have something to debug. ![salt-master errors](/static/img/server_management/h1_049.png "salt-master errors") I found [this post](https://stackoverflow.com/questions/48532595/must-specify-saltenv-base) on stackoverflow and decided to try removing the addition i made so the `gitfs_remotes` looks like this again: gitfs_remotes: - https://github.com/heiskane/salt-states.git I restarted salt-master and tried applying my state with the following command: sudo salt slave-1 state.apply hello saltenv=main ![gitfs success](/static/img/server_management/h1_050.png "gitfs success") As seen in the image this was a success so now i want to either add the `main` branch as the base environment or try to rename the main branch to `master` like it probably should be to begin with. After failing to find any clear documentation on how to change the default branch i decided to just change the name of my `main` branch to `master`. I found [this handy guide](https://www.git-tower.com/learn/git/faq/git-rename-master-to-main/) that showed how to do the opposite of what i was doing but it was easy to go off that anyway. I started by renaming my branch to master and pushing it to github. git branch -m main master git status git push -u origin master After doing this i had to go to the repository branch settings on github and change the default branch to the `master` branch i just created. ![github default branch](/static/img/server_management/h1_051.png "github default branch") After changing the default branch i deleted the `main` branch with the following command. git push origin --delete main Now running `sudo salt 'slave-1' state.apply hello` will look for the `hello` state in my github repository. ![gifs working](/static/img/server_management/h1_052.png "gifs working") Do note that at this point salt looks for states **only** in my github repository. This can be changed so that salt uses both the remote repository and the local `/srv/salt` directory by changing `fileserver_backed` configuration as follows: fileserver_backend: - gitfs - roots Now i can run states from `/srv/salt` **and** my repository on github. To verify this works i ran a state from `/srv/salt`. ![local state](/static/img/server_management/h1_053.png "local state") With all of that out of the way it was time to create a new state and this time i wanted to configure a proxy that would work with `proxychains`. I had experimented a bit with proxies like `squid` but this time i wanted to get a `SOCKS5` proxy running. From what i have read there are many advantages `SOCKS5` has over an `http` proxy like squid. According to [this article](https://securityintelligence.com/posts/socks-proxy-primer-what-is-socks5-and-why-should-you-use-it/) the *SOCKS is designed to route any type of traffic generated by any protocol or program.* To achieve this i decided to try `dante` and mostly used [this guide](https://community.hetzner.com/tutorials/install-and-configure-danted-proxy-socks5) for it. I started by actually installing it. sudo apt install dante-server Note that when i create the slaves with vagrant they are updated in the process so i dont do that here. As instructed in the guide i made a backup for dantes configuration file with the following command. sudo mv /etc/danted.conf /etc/danted.conf.bak Now to create the actual configuration file i opened it with `sudoedit /etc/danted.conf` and copy-pasted the configuration from the guide into my file. I only changed the interface to `eth1` because that is the interface for the NAT network my machines are on. Ill leave my current configuration here. logoutput: /var/log/socks.log internal: eth1 port = 1080 external: eth1 clientmethod: none socksmethod: none user.privileged: root user.notprivileged: nobody client pass { from: 0.0.0.0/0 to: 0.0.0.0/0 log: error connect disconnect } client block { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect error } socks pass { from: 0.0.0.0/0 to: 0.0.0.0/0 log: error connect disconnect } socks block { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect error } After a quick restart with `sudo systemctl restart danted` i made sure it was working with `sudo systemctl status danted` and `ss -ltn`. ![dante running](/static/img/server_management/h1_054.png "dante running") As seen in the image the dante service is running and listening on port 1080. To actually use it i wanted to use `proxychains4`. This can be installed with the following command. I did this part on another VM on the same network. sudo apt install proxychains4 To configure proxychains i opened the configuration file with `sudoedit /etc/proxychains4.conf` and added the following configuration. dynamic_chain proxy_dns remote_dns_subnet 224 tcp_read_time_out 15000 tcp_connect_time_out 8000 [ProxyList] socks5 172.28.128.88 1080 Finally to use the dante proxy with proxychains4 i used the following command. proxychains curl http://heiskanen.rocks While the first time i ran the command it took a while to respond but it worked and sped up on the subsequent tries. ![proxychains curl](/static/img/server_management/h1_055.png "proxychains curl") As a quick note my website is returning a 301 response because the http requests are redirected to https. With the manual configuration out of the way it was time shut these machines down and spin up some fresh minions. I started working on the sls file in my git repository by creating the `init.sls` file and added a simple state to install dante. install_dante: pkg.installed: - name: dante-server service.running: - name: danted - enable: True - require: - pkg: install_dante Trying to run it i quickly realized that i would have to push the changes first to apply this state. I didnt want to push what i havent tested yet so i tried to add the following configuration to my salt master. gitfs_remotes: - https://github.com/heiskane/salt-states.git - file:///home/niko/salt-states I believe this is the way to make it work but for some reason it didnt. So for now ill work on this state locally then add it to the repository once its working. After moving my dante directory to `/srv/salt` i had to cange the permissions to be able to edit it. sudo chown -R root:root dante/ I tried breaking the local `dante/init.sls` to see which one get excecuted first. Applying the state before i moved the file was successful so i know it works. After breaking the local file everything still ran just fine so salt was getting the state from github first. I tried changing the order of the `fileserver_backend` so they would look like this. fileserver_backend: - roots - gitfs But this didnt make it prefer the local files either so i decided to just remove the dante directory from my repository for now and work on it locally. Okay so running the state wasnt **entirely** successful. The installation went just fine but when trying to make sure it is running i got the following error. ID: install_dante Function: service.running Name: danted Result: False Comment: Service danted is already enabled, and is dead Started: 15:19:58.662098 Duration: 144.061 ms At this point i remembered that when manually testing it wasnt successfully running before i added the configuration file so this behaviour i somewhat expected. I guess i have to add the `service.running` module later and just add the config file first. To get the config on the target i used a similar state. add_config: file.managed: - name: /etc/danted.conf - source: salt://dante/danted.conf - require: - pkg: install_dante With this file added i wanted to add the `service.running` module back but after adding the file this time. I edited my `dante.conf` just so it would be diffrent and the `watch` would reload dante service. reload_dante: service.running: - name: danted - enable: True - reload: True - watch: - file: /etc/danted.conf - require: - pkg: install_dante Trying to run this still gave me an error. ID: reload_dante Function: service.running Name: danted Result: False Comment: Failed to reload danted.service: Job type reload is not applicable for unit danted.service. Started: 15:37:20.447768 Duration: 28.773 ms Remembering that i used `restart` in my manual configuration i tried changing the `reload` to `restart` in the sls file. I changed the conf file again and applied the state. This time it ran without any issues. ---------- ID: reload_dante Function: service.running Name: danted Result: True Comment: Service restarted Started: 15:38:43.306572 Duration: 66.47 ms Changes: ---------- danted: True Summary for slave-1 ------------ Succeeded: 3 (changed=2) Failed: 0 ------------ Total states run: 3 Total run time: 117.837 ms At this point i ran `systemctl status danted` and `ss -ltn` on the slave to verify that the `danted` service was running and listening on the specified port. Lastly the most essential test is to actually use it for what its for. I logged into a fresh machine then installed and configured `proxychains4` as i had done previously only changing the proxy ip. Running the same `proxychains` command shows that the configuration was successful. ![again proxy curl](/static/img/server_management/h1_056.png "again proxy curl") With the proxy up and running i want to try and get it working with authentication. I followed the previous guide again and made some changes to the `/etc/danted.conf` so that it looks like this. I did this part locally on the slave first # danted.conf logoutput: /var/log/socks.log internal: eth1 port = 1080 external: eth1 clientmethod: none socksmethod: username user.privileged: root user.notprivileged: nobody client pass { from: 0.0.0.0/0 to: 0.0.0.0/0 log: error connect disconnect socksmethod: username } client block { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect error } socks pass { from: 0.0.0.0/0 to: 0.0.0.0/0 log: error connect disconnect } socks block { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect error } Running the `proxychains` command again gives *denied* now as expected. vagrant@slave-3:~$ proxychains4 curl http://heiskanen.rocks [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.14 [proxychains] Dynamic chain ... 172.28.128.89:1080 ... heiskanen.rocks:80 <--denied curl: (7) Couldn't connect to server With that tested i added username and password to the `/etc/proxycahins4.conf` file like this. [ProxyList] # add proxy here ... # meanwile # defaults set to "tor" socks5 172.28.128.89 1080 vagrant vagrant Running the command again gives a successful response from the website. [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.14 [proxychains] Dynamic chain ... 172.28.128.89:1080 ... heiskanen.rocks:80 ... OK
The document has moved here.