redeploy server with new public IP about discussions

[nopdotcom]

Redeployment is perhaps not quite the right goal. From a user’s point of view, the minimum change is to preserve existing keys, yet regenerate all the docs and config files that have a hardcoded IP address.

It would be great if this could be triggered on the streisand host, but it may be easier to implement as an Ansible task on the original deployment host. (I’m not an Ansible person.)

[ridercz]

It would be better to use host name instead of IP address when possible (when specified during config). Streisand uses host name for getting Let's Encrypt certificate anyway. IP change can be solved by using cloud provider's solution (if any), or independent DDNS service like https://www.freemyip.com/.

[nopdotcom]

One important use case here: server restart in environments where public IP addresses are allocated per-boot.

On AWS, we get a fixed public IP address and it shows up as the address on the network interface.

On Lightsail and some other services, you create the VM, then assign a static IP to the VM in the management interface. (Reboot for safety.) The public IP address shows up on the interface.

On Azure, you can allocate fixed public IP addresses, but that address does not show up as an address on the network interface. Actually, the static IP documentation kinda confuses me. There's an Ansible module for Azure IP addresses.

I'm kinda exhausted with Windows for a while, and I need to work on overdue documentation next. So this is not in my short-term plans, but I will take a look at it as an Ansible exercise eventually.

The pricing structure for Azure is not ideal for Streisand usage. DO and its imitators have 1TB of traffic built into their plans. Vultr has low overage rates as well.

I can imagine that having an endpoint inside Azure might be superior for ingress reachability (it's corporate, so it may not get blanket-banned) and egress reachability (sites that ban proxies may not notice Azure, who knows). Has anybody had experience with this?

[ridercz]

First, this problem is not Azure-specific. For users who don't use Streisand all the time, but only when connected to unreliable networks, makes sense to suspend/undeploy the VM when not in use and spin it up only when needed. Every time it will get different IP address.

Second, Azure may be preferred by users from financial standpoint. At this time, Microsoft has an offer that you can get a small VM (with plenty of computing power for Streisand) for one year for free. Also, developers with Visual Studio subscriptions get some Azure credits included for free. So Azure is for many people good way to get a VM for free or for pennies. Static IP addresses in Azure cost additional money.

Third, what is Azure-specific is that Streisand uses internal IP address of the VM (from 10.x.x.x range), not external one, so following the instructions to the letter won't work. There is a 1:1 NAT and layer for load balancing, the machine isn't directly connected to the Internet with public IP.

All these issues can be solved by using a host name instead of IP address in instruction and profile files, when known. Streisand asks for it and uses it for Let's Encrypt certificate anyway.

I use L2TP/IPsec and OpenVPN and both work just fine with host names without IP address. I'm not sure about other protocols, if there isn't something requiring use of raw IP, but at least for the above mentioned, the problem can be easily solved.

Unfortunatelly, I can't propose direct change and do a pull request, because I don't know Ansible :-(.

[nopdotcom]

I think I need to break this up into a couple of responses, because what you're saying is important. I don't know all this stuff, so it'll take me a little time to work through it.

For my own curiosity, I decided to price unattached IP addresses across providers. I am not saying this is a good deployment strategy, but it can rule out some providers. Like, there's little point in doing this with regular-rate GCE.

Provider	Unattached cost/month	Local address	Notes
Vultr	$3	Yes	Attached or unattached static IP
Digital Ocean	$4	?
AWS EC2	$4	Yes
AWS Lightsail	$4?	Yes	Presumably EC2 pricing
Azure	$2.50	Yes
Google GCE	$7	Yes	See below
Linode	N/A		Full price

GCE notes

Google has an Always Free tier. You get a micro instance. Presumably you can attach a static IP address; that avoids the "unattached IP" fee. I haven't tried this yet.

[nopdotcom]

Azure is an OK choice for people already in the Microsoft ecosystem. I haven't had a VS license in a while, so I didn't know about the Azure deal: With Visual Studio Pro you get $50/mon in credits. Annual retail pricing is $539/yr, but many people already have the subscription. I'd be interested in Azure if that were the deal I had too!

Azure deploys break often, because none of us are very good about testing it. I would love to have somebody periodically test it and report.

Right now, deploys to Azure are especially broken because of an upstream Ansible bug. We didn't notice. :-(

[nopdotcom]

Casual examination shows Digital Ocean has "floating IPs" which really are just NAT. So if we want to automatically create persistent IP address on DO, we need some coding.

This is strictly for better experience with VM stop/start; unattached DO floating IPs cost $4/mon, compared to the $5/mon for a running instance.

@ridercz, I'm not an Ansible person either--I'm learning, but I don't expect other people to do so.

If you don't mind setting up another server, it would be helpful to get a diff of your changes in /etc. That's easier than it looks:

# Run as root
# sudo -s
cd /etc
apt-get install etckeeper
git tag begin
# Do your changes here
vi /etc/hosts
date -I >/etc/streisand_build_date
# etc
# Optional: checkpoint your progress
etckeeper commit "Added host entries"

git diff begin
git diff begin >/tmp/diffs

Given that, I bet I can we can make something happen in Ansible.

[rdbox]

I did not understand the solution found?
There is a lot of information, but I do not see a solution?????

Also looking for a solution

[rdbox]

To mean while there is a hard decision it to search for coincidence ip server and to replace on new ip.
The other solutions did not find

sed -i -- 's/foo/bar/g' *
perl -i -pe 's/foo/bar/g' ./* 

and another option

grep -rli 'old-word' * | xargs -i@ sed -i 's/old-word/new-word/g' @

maybe someone will be out of the developers and come up with an automatic script