Read the article here:
https://www.xda-developers.com/alternative-to-tailscale-or-nginx-remote-access-home-lab/
Read the article here:
https://www.xda-developers.com/alternative-to-tailscale-or-nginx-remote-access-home-lab/
Original: https://dev.to/armiedema/opening-up-port-80-and-443-for-oracle-cloud-servers-j35
Are you working on setting up your Oracle Cloud server and are facing issues with sites rendering as expected? Such as, getting time out issues when navigating to the site’s url?
Before we get into the steps of making port 80 and 443 work properly on an Oracle server, you may be wondering why Cleavr only integrates with some of the free server options and does not provide paid tier options. In short, we wanted to provide users with a free server option and Oracle in one of the few providers that offers a decent free server option. However, the experience to connect with Oracle accounts is very rough around the edges plus these oddities around port connections have led us to delay integrating with Oracle further until their experiences improve.
But, let’s get back to the main issue. When you provision a server via Oracle’s cloud interface, ports 80 and 443 won’t be fully opened until you make the following updates.
For this first step, you’ll need to access your Oracle Cloud account.
Port 80 and 443 will be closed by default. Assuming you plan to add websites to the server, open port 80 and 443 by clicking on Virtual Cloud Network from the server instance details screen.
Click Security List on the left menu.

Click on the security list
Click Add Ingress Rules
Add the following source and port –
Add the ingress rule for port 80. Do the same process for port 443.
At this juncture, you may be led to believe that ports 80 and 443 are opened. Afterall, you just set the ingress rule that opens up the ports.
Not so fast!
It’d be best and most expediant to scan the server ports to make sure that these ports are actually opened to the outside world.
We’ll use Doneo.io’s server port scanning tool to scan the server after making the above updates.
In the above, we can see that we still have some work to do to open up port 443.
For this step, we’ll need to SSH into the server so we can run some terminal commands.
Run the following commands:
iptables -I INPUT 6 -m state --state NEW -p tcp --dport 443 -j ACCEPT
netfilter-persistent save
This will update the iptables to allow port 443. If port 80 was blocked after performing a port scan, then also run the above but swap out 443
with 80
.
Now, run another server port scan to see if 443 is open.
We can see from the screenshot above from the Doneo.io port scan that 443 is now open.
Your http and https sites should now be accessible to the public.
Hopefully, this article saves you some time and stress as this can be a frustrating issue to resolve.
Steps:
1. Set Up Passwordless SSH Access
Ensure that the server running Let’s Encrypt (Server1) can connect to the target server (Server2) via SSH without a password:
On Server1, generate an SSH key pair (if not already created):
ssh-keygen -t rsa -b 4096
Copy the public key to Server2:
ssh-copy-id user@server2
Replace user
with the username on Server2.
2. Create a Script for Copying Certificates
On Server1, create a script (e.g., copy_cert.sh
) to copy the certificate files to Server2:
#!/bin/bash
REMOTE_USER="user"
REMOTE_SERVER="server2"
REMOTE_PATH="/path/to/certificates"
scp /etc/letsencrypt/live/yourdomain.com/fullchain.pem ${REMOTE_USER}@${REMOTE_SERVER}:${REMOTE_PATH}/
scp /etc/letsencrypt/live/yourdomain.com/privkey.pem ${REMOTE_USER}@${REMOTE_SERVER}:${REMOTE_PATH}/
Replace yourdomain.com
with your domain.
Replace /path/to/certificates
with the directory on Server2 where the certificates should be stored.
Make the script executable:
chmod +x copy_cert.sh
3. Test the Script
Run the script manually to ensure the certificates are copied successfully
./copy_cert.sh
4. Use Certbot’s --deploy-hook
Modify the Certbot renewal configuration to include a deploy hook that runs the script after successful renewal. You can add this directly when renewing or use an existing configuration:
certbot renew --deploy-hook "/path/to/copy_cert.sh"
Alternatively, edit the renewal configuration file (usually located at /etc/letsencrypt/renewal/yourdomain.com.conf
):
renew_hook = /path/to/copy_cert.sh
5. Ensure Scheduled Renewal
Certbot typically installs a cron job or systemd timer for automatic renewal. Verify it:
For cron: Check /etc/cron.d/certbot
.
For systemd: Check certbot.timer
with:
systemctl list-timers | grep certbot
6. Restart Services on Server2 (Optional)
If the certificates are used by a service (e.g., Nginx or Apache) on Server2, modify the script to restart the service:
ssh ${REMOTE_USER}@${REMOTE_SERVER} "sudo systemctl reload nginx"
Now, whenever the certificate is renewed on Server1, it will automatically be copied to Server2 and (optionally) reload the relevant service.
https://support.system76.com/articles/desktop-environment/#different-desktop-environments
Change Default Display Manager:
sudo dpkg-reconfigure gdm3
Check which display manager is running:
systemctl status display-manager.service or $ cat /etc/X11/default-display-manager
Restart GDM:
sudo systemctl restart gdm