Hi Chris,
On Mon, 27 Jun 2022, Chris Muller wrote:
Hi Levente,
I'm willing to support the migration of source.squeak.org to the new server, if desirable, including some beyond the initial migration.
Great! Thank you!
Thanks for any assistance in helping me get going. After adjusting my ~/.ssh/config file to the new IP addresses and trying to ssh into ian, I got a "This account is currently not available." message (see below).
Yes, it is not possible to "ssh into" to the new ian. You're not supposed to be able to connect that way to the "old" ian either. Instead, you should use ProxyJump directive in your ssh config file:
Host new-ian HostName 116.203.28.174 User ssh IdentityFile <path_to_your_ssh_key> IdentitiesOnly yes PreferredAuthentications publickey PubkeyAuthentication yes
Host 10.98.1.* User chrismuller ProxyJump new-ian IdentityFile <path_to_your_ssh_key> IdentitiesOnly yes PreferredAuthentications publickey PubkeyAuthentication yes
And then, you can connect to a given server by specifying its internal IP address. E.g.:
$ ssh 10.98.1.4
Or, you can give it a custom name:
Host new-andreas HostName 10.98.1.4 User chrismuller ProxyJump new-ian IdentityFile <path_to_your_ssh_key> IdentitiesOnly yes PreferredAuthentications publickey PubkeyAuthentication yes
And connect with
$ ssh new-andreas
Levente
I tried one more time with my username, but it reported "Too many authentication failures". It's possible I did something wrong.
- Chris
~$ ssh ian The authenticity of host '116.203.28.174 (116.203.28.174)' can't be established. ED25519 key fingerprint is SHA256:CmQ9VWvhitm5WwLc5GTsbWap47WyfLH4OCUILrYBSYM. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '116.203.28.174' (ED25519) to the list of known hosts. Linux ian 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Jun 22 11:13:01 2022 from 91.83.13.73 This account is currently not available. Connection to 116.203.28.174 closed.
~$ ssh chrismuller@ian Received disconnect from 116.203.28.174 port 22:2: Too many authentication failures Disconnected from 116.203.28.174 port 22 ____
On Mon, May 23, 2022 at 4:08 AM Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Marcel,
We currently have a server which has the containers set up on them. The ip address of the server is 116.203.28.174.
Everyone who has an account on rackspace can ssh into to that server with their existing ssh keys using the ssh user just like on ian but, the ssh port is kept 22 for now.
The containers are avaiable on the 10.98.1.0/24 prefix: 10.98.1.2 alan 10.98.1.3 adele 10.98.1.4 andreas 10.98.1.5 dan 10.98.1.6 david 10.98.1.7 scott 10.98.1.8 ted
Everyone who has an account to the servers on rackspace can log into these containers with their existing ssh keys, and everyone has sudo access the same way as on rackspace.
We unified the account names so Vanessa and Craig have the username vanessa and craig on all servers they had access to, respectively.
The setup is not complete yet. There still are things left to do. The containers will surely be rebuilt, perhaps the whole server as well, so don't expect things to persist yet.
What's left to do before migration to the new server can start is to:
- configure the firewalls of the individual containers
- configure the main server's firewall to forward ports where needed to
- create volumes for some of the containers as we don't have enough space
on the server to host everything
- make the server restart-proof
Since we're short on time, we won't automate the installation of software into containers yet. But it would be worth to puruse that to have a well-documented and repeatable installation process.
We encourage everyone to log in and have a look around to see if things work as expected.
Levente
P.S.: @Tony, your key has been added to the authorized keys as well with the username tonyg.
On Wed, 18 May 2022, Marcel Taeumel wrote:
Hi Levente -- What's the current status on the playbooks? :-)
Best, Marcel
Am 10.05.2022 13:19:20 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>: Hi Levente --Thank you for doing this!
I just set up an account at Hetzner and will ask the SFC/Pono whether that project-based solution would work for them.
I will also try to set up Hetzner's Cloud DNS with some help from Tobias. Then we can start asking those domain holders to update their entries. And the switch over from Rackspace to Hetzner will be easier once we set up Squeak's services there.
Best, Marcel
Am 26.04.2022 22:28:05 schrieb Levente Uzonyi <leves@caesar.elte.hu>: Hi Marcel, On Thu, 21 Apr 2022, Marcel Taeumel wrote: > Hi Levente -- > > At yesterday's board meeting, we agreed on migrating back to Hetzner again. We are also grateful for the options/plans you outlined. We agreed on the following: > > - Single server with containers > - Plan #3 (i.e., CX41 + 290GB) if it won't be too difficult to add extra storage later if needed; otherwise Plan #2 (i.e., CX41 + 540GB) > - No built-in backup feature of the server (as we should figure out a way to backup both server and storage anyway) > > While there are a few more volunteers, we would be *very* happy if you would organize (or even perform most of) the migration. Feel free to contact the following people to distribute some of the effort as they are happy to help as well: > > - Bruce (bruce.oneel@pckswarms.ch) > - Tony (tonyg@leastfixedpoint.com) > - Dave (lewis@mail.msen.com -- SqueakSource) > - Chris (ma.chris.m@gmail.com -- SqueakSource) > - Marcel (marcel.taeumel@hpi.de -- DNS updates via e-mail) > > Yes, you can go ahead and write ansible playbooks to set up servers using lxc containers. If you encounter unforeseen challenges that could eat up a lot of your time, do not hesitate but inform the board. The playbooks for the server layout are in progress. There are a few things that need some extra time: - we're upgrading the OS from jessie to bullseye, and there are some differences how lxc works in bullseye than in other debian versions - we need IPv6 support (because of the smtp server) and no DHCP (containers get a dynamic IP address by default but it's better for us if they are static) - set up wireguard and route traffic to the containers through it - set up the firewall to replicate what's on rackspace > > We assume that all current services and (SSH) login information can be retained. The idea is to use wireguard[1] as the main connection point, and then log in to the containers through ssh. That way we could avoid the tcp-over-tcp access to the servers and have different layers of security. To answer your question, yes, the existing users will be recreated in the containers and the ssh keys will be copied there as well, even though they'll only be needed to manually fix anomalies. > > *** > > To get started, please set up an account at Hetzner and configure the required service. DO NOT use any existing account of your own as we will share the credentials with the SFC so that they can enter/update the billing information. So, create a new account and drop the credentials here: > > https://www.hpi.uni-potsdam.de/hirschfeld/cloud/s/PsrPXGgHM5HjkBx > PW: GLGMqj7cD9 > > I will then contact Pono/SFC to enter the billing info. If there is any chance that you might pay the first month from your own pocket, we will make sure to reimburse you. > > (If you learn about that sub-accounts at Hetzner can actually be used to change billing info, please let me know as we then do not have to pass on our credentials to the SFC. Yet, to my knowledge, this is not possible.) According to the documentation[2], the SFC should create a Project for the Squeak servers, and invite someone from the Squeak community (preferrably from the board) as an Admin of that Project. The Admin can create any kind of resources but does not have access to the billing information. If we automate as many things as I planned with ansible, only an API key will need to be created, the rest will be done by the ansible playbooks. The Admin user can invite box-admins as Restricted users to maintain the resources if needed. For the DNS, we can use Hetzner's DNS Console[3][4]. Since it's free, we don't have to get the SFC involved with that. For example, the Admin account can be the owner. Levente [1] https://www.wireguard.com/ [2] https://docs.hetzner.com/cloud/general/faq/#what-are-projects-and-how-can-i-use-them [3] https://www.hetzner.com/dns-console [4] https://docs.hetzner.com/dns-console > > *** > > What do you think? :-) Is it feasible to be done with this by the end of May? What is your (most defensive) estimate? > > Best, > Marcel (on behalf of the Squeak Oversight Board) > > >