-
Star
(195)
You must be signed in to star a gist -
Fork
(35)
You must be signed in to fork a gist
-
-
Save hjbotha/f64ef2e0cd1e8ba5ec526dcd6e937dd7 to your computer and use it in GitHub Desktop.
| #! /bin/bash | |
| # NEWLY ADDED BACKUP FUNCTIONALITY IS NOT FULLY TESTED YET, USE WITH CARE, ESPECIALLY DELETION | |
| # Developed for DSM 6 - 7.0.1. Not tested on other versions. | |
| # Steps to install | |
| # Save this script in one of your shares | |
| # Edit it according to your requirements | |
| # Backup /usr/syno/share/nginx/ as follows: | |
| # # cd /usr/syno/share/ | |
| # # tar cvf ~/nginx.tar nginx | |
| # Run this script as root | |
| # Reboot and ensure everything is still working | |
| # If not, restore the backup and post a comment on this script's gist page | |
| # If it did, schedule it to run as root at boot | |
| # through Control Panel -> Task Scheduler | |
| HTTP_PORT=81 | |
| HTTPS_PORT=444 | |
| BACKUP_FILES=true # change to false to disable backups | |
| BACKUP_DIR=/volume1/apps/free_ports/backup | |
| DELETE_OLD_BACKUPS=false # change to true to automatically delete old backups. | |
| KEEP_BACKUP_DAYS=30 | |
| DATE=$(date +%Y-%m-%d-%H-%M-%S) | |
| CURRENT_BACKUP_DIR="$BACKUP_DIR/$DATE" | |
| if [ "$BACKUP_FILES" == "true" ]; then | |
| mkdir -p "$CURRENT_BACKUP_DIR" | |
| cp /usr/syno/share/nginx/*.mustache "$CURRENT_BACKUP_DIR" | |
| fi | |
| if [ "$DELETE_OLD_BACKUPS" == "true" ]; then | |
| find "$BACKUP_DIR/" -type d -mtime +$KEEP_BACKUP_DAYS -exec rm -r {} \; | |
| fi | |
| sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)80\([^0-9]\)/\1$HTTP_PORT\2/" /usr/syno/share/nginx/*.mustache | |
| sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)443\([^0-9]\)/\1$HTTPS_PORT\2/" /usr/syno/share/nginx/*.mustache | |
| if which synoservicecfg; then | |
| synoservicecfg --restart nginx | |
| else | |
| synosystemctl restart nginx | |
| fi | |
| echo "Made these changes:" | |
| diff /usr/syno/share/nginx/ $CURRENT_BACKUP_DIR 2>&1 | tee $CURRENT_BACKUP_DIR/changes.log |
I was using platform DS3622xs+ with [7.1.0-42661]. I then run your script which move the port effectively and later and I realize I didn't pick the right one for quicksync transcode. I redo it using ARPL and switch to 918+. Now I can't seems to get back into the ip:5000 site after migrate. Do you know if this have any affect on it? I know the script only reassign port 80 and 443 but I don't understand how synology use all of their webservices so I just want to make sure this port reassignment didn't mess it up as I'm finding way to fix this.
I was using platform DS3622xs+ with [7.1.0-42661]. I then run your script which move the port effectively and later and I realize I didn't pick the right one for quicksync transcode. I redo it using ARPL and switch to 918+. Now I can't seems to get back into the ip:5000 site after migrate. Do you know if this have any affect on it? I know the script only reassign port 80 and 443 but I don't understand how synology use all of their webservices so I just want to make sure this port reassignment didn't mess it up as I'm finding way to fix this.
This script only affects the ports you tell it to. Refer to the updated comment: https://gist.github.com/hjbotha/f64ef2e0cd1e8ba5ec526dcd6e937dd7?permalink_comment_id=4534225#gistcomment-4534225
This system is still back on 7.2.1, I’m holding off on 7.2.2 until I see how the sweeping changes of removing certain codecs affects things, but I went digging around in the nginx folder. I didn’t find any other instances of 80/443 being used in there. But I did notice something about https… but I’m still very new to how nginx works and didn’t want to break a bunch of things without fully understanding the implications or knowing how to undo my changes.
Same goes for you, it only affects the ports listed in the script. Get used to reading scripts if you want to manage a server like this. For security reasons you should always know what a script does before you run it.
In today's world, it's easy to get a free LLM like ChatGPT to explain the code to you, so that you can understand it.
I was using platform DS3622xs+ with [7.1.0-42661]. I then run your script which move the port effectively and later and I realize I didn't pick the right one for quicksync transcode. I redo it using ARPL and switch to 918+. Now I can't seems to get back into the ip:5000 site after migrate. Do you know if this have any affect on it? I know the script only reassign port 80 and 443 but I don't understand how synology use all of their webservices so I just want to make sure this port reassignment didn't mess it up as I'm finding way to fix this.
This script only affects the ports you tell it to. Refer to the updated comment: https://gist.github.com/hjbotha/f64ef2e0cd1e8ba5ec526dcd6e937dd7?permalink_comment_id=4534225#gistcomment-4534225
This system is still back on 7.2.1, I’m holding off on 7.2.2 until I see how the sweeping changes of removing certain codecs affects things, but I went digging around in the nginx folder. I didn’t find any other instances of 80/443 being used in there. But I did notice something about https… but I’m still very new to how nginx works and didn’t want to break a bunch of things without fully understanding the implications or knowing how to undo my changes.
Same goes for you, it only affects the ports listed in the script. Get used to reading scripts if you want to manage a server like this. For security reasons you should always know what a script does before you run it.
In today's world, it's easy to get a free LLM like ChatGPT to explain the code to you, so that you can understand it.
I actually did read the script but wasn’t sure it and my problem wasn’t related and I fixed it. And I use perplexity and got. But ya sure
Model: DS1821
DSM Version: 7.2.2-72806 Update 3
Issue: The script has been configured to change the Nginx port settings, but after rebooting the system, Nginx continues to use port 443.
sh-4.4$ sudo netstat -tulpn | grep '80\|443'
Password:
tcp 0 0 0.0.0.0:5443 0.0.0.0:* LISTEN 14246/nginx: master
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 13809/smbd
tcp 0 0 0.0.0.0:5880 0.0.0.0:* LISTEN 14246/nginx: master
tcp 0 0 0.0.0.0:5080 0.0.0.0:* LISTEN 14246/nginx: master
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 14246/nginx: master
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 13809/smbd
tcp 0 0 0.0.0.0:6690 0.0.0.0:* LISTEN 26800/syncd
tcp6 0 0 :::5443 :::* LISTEN 14246/nginx: master
tcp6 0 0 :::139 :::* LISTEN 13809/smbd
tcp6 0 0 :::5880 :::* LISTEN 14246/nginx: master
tcp6 0 0 :::5080 :::* LISTEN 14246/nginx: master
tcp6 0 0 :::443 :::* LISTEN 14246/nginx: master
tcp6 0 0 :::445 :::* LISTEN 13809/smbd
tcp6 0 0 :::6690 :::* LISTEN 26800/syncd
tcp6 0 0 :::9090 :::* LISTEN 23980/docker-proxy
udp 0 0 127.0.0.1:805 0.0.0.0:* 12077/statd
Hi @julichan ,
Thank you for your guidance.
I currently have self-signed certificates set up for Traefik, and after testing my Docker Compose setup on my local host, I'm able to access traefik.contoso.com and confirm that the certificates I've defined are being used successfully.
However, according to your guide, when I configure other ports on Synology—specifically 8088 and 8443 mapped to container ports 80 and 443—I notice that accessing the Traefik domain only presents the certificates issued by Synology.
Could you advise me on how to configure it so that Synology does not try to assign TLS certificates, allowing me to bypass this issue?
I was using platform DS3622xs+ with [7.1.0-42661]. I then run your script which move the port effectively and later and I realize I didn't pick the right one for quicksync transcode. I redo it using ARPL and switch to 918+. Now I can't seems to get back into the ip:5000 site after migrate. Do you know if this have any affect on it? I know the script only reassign port 80 and 443 but I don't understand how synology use all of their webservices so I just want to make sure this port reassignment didn't mess it up as I'm finding way to fix this.
This script only affects the ports you tell it to. Refer to the updated comment: https://gist.github.com/hjbotha/f64ef2e0cd1e8ba5ec526dcd6e937dd7?permalink_comment_id=4534225#gistcomment-4534225
This system is still back on 7.2.1, I’m holding off on 7.2.2 until I see how the sweeping changes of removing certain codecs affects things, but I went digging around in the nginx folder. I didn’t find any other instances of 80/443 being used in there. But I did notice something about https… but I’m still very new to how nginx works and didn’t want to break a bunch of things without fully understanding the implications or knowing how to undo my changes.
Same goes for you, it only affects the ports listed in the script. Get used to reading scripts if you want to manage a server like this. For security reasons you should always know what a script does before you run it.
In today's world, it's easy to get a free LLM like ChatGPT to explain the code to you, so that you can understand it.
Yeah, thanks. I’ve been writing scripts for years. I can read it just fine, it still didn’t work on three different Syno units. And as I said, if you were paying attention, I went digging in those locations that the script was altering and wasn’t able to find things. So, I found a way without having to alter the DSM by completely bypassing it all together with a different, much better, proxy server. Took less time than I spent trying to get this to work.
Hi @julichan ,
Thank you for your guidance.
I currently have self-signed certificates set up for Traefik, and after testing my Docker Compose setup on my local host, I'm able to access traefik.contoso.com and confirm that the certificates I've defined are being used successfully.
However, according to your guide, when I configure other ports on Synology—specifically 8088 and 8443 mapped to container ports 80 and 443—I notice that accessing the Traefik domain only presents the certificates issued by Synology.
Could you advise me on how to configure it so that Synology does not try to assign TLS certificates, allowing me to bypass this issue?
Hello @mrkhachaturov,
Thanks for reading my posts.
Your self signed certificates are used to communicate between syno's proxy and traefik so when you open your browser to your traefik url, the browser will use the certificate configured in your synology dsm. I don't use that configuration anymore (i use a macvlan on traefik and contact directly the container) so I cannot confirm if the following configuration will suit you or work as expected.
You can open the control panel on your synology, then go to Security and Certificate. From this location, you can import several certificates. The certificate your browser will use will depend on the url it calls your server with. Click the setting button and a pop-up will open where you can select which certificate is used for which service and amongst them, you ll see each of the url configured in synology's reverse proxy. Change the one that match your traefik url after importing or creating a matching certificate.
Ps: somehow, the uploaded image won't show up, bug?
Hope that helps ;)
Thank you, @julichan.
I’ve already updated my setup to use a macvlan configuration with a dedicated VLAN ID.
A little bit bit of finetuning and works like a charme :-)
A little bit bit of finetuning and works like a charme :-)
@ctrlaltdelete007 what were the issues that required you to do some finetuning?
Edit: I was able to get it working, I just needed to reboot. I have my Synology set to run this script at reboot as well, which I believe is what fixed it. The script took the port away from Synology WebGUI at reboot.
@ZaxLofful , i ran the script at reboot as well but running sudo netstat -tulnp | grep ':443 ' shows that my ports are still tied to synology's nginx :( any thoughts?
I'm running DS723+ on DSM 7.2.2-72806 Update 1
I have a DS1521+ running DSM 7.2.2-72806 Update 2 and it works.