Closed makp0 closed 1 year ago
Hi @makp0
You don't need to connect directly with root user after host custom.
Just use root via "sudo -i" if needed
Hi @makp0
You don't need to connect directly with root user after host custom.
Just use root via "sudo -i" if needed
I've already figured by trial and error 🙂 But thank you for swift response.
Maybe it's worth mentioning in docs that default user is caretaker which sudos into root using "sudo -i". Because it took me quite a time to figure. It should facilitate log extraction for any future issues.
Either we put a docs label on this issue or close it. Whatever you think necessary
I think we need to enhance the documentation on this whole infra and auto-magic service account creation. Adding label and an associated issue.
@makp0 Could you please tell me your path through documentation? How you landed on the project, which howto/tutorial was useful, which one were confusing? I'll help a lot to have early adopters point of view.
@aurelienmaury
I was in search of an all-in-one (Consul, Nomad, Vault) production-grade HashiCorp pack solution that can run in an affordable cloud. I first tried searching on GitHub, but your project didn't stand out much there with just 30+ stars. This is surprising given the quality of your project.
I then checked out these awesome project lists:
Make sure your project is featured on at least the last two lists.
I found some interesting tools like Caravan with HA 3 server setup in the more expensive AWS, Azure, and GCP clouds. Their AWS option was broken, but Azure worked. It covered my need for a production environment, but not a development one. So I continued searching and eventually found your project.
As a long-time Hetzner user, I was initially hesitant to try Scaleway. Additionally, I've always been a bit wary of Ansible without any solid reason.
I appreciate your documentation, but there is always room for improvement:
export SCW_DEFAULT_REGION="..."
export SCW_DEFAULT_ZONE="..."
I finally guessed correctly on my fifth attempt:
export SCW_DEFAULT_REGION="fr-par"
export SCW_DEFAULT_ZONE="fr-par-1"
You should either explain where to find these values or consider whether it makes sense to infer the region from the zone. Is the region always a substring of the zone?
I'm a big fan of convenience scripts. I found your Makefile to be too granular, which led to me constantly checking and waiting for each stage to finish. I ended up creating a script for a one-line deployment since I was redeploying frequently while trying to find a working branch and commit. Consider simplifying your Makefile and providing a convenience script in your documentation.
If you include a convenience script in your documentation, consider placing it on the front page. The script could prompt users to fill in the .env.secrets
variables while showing example values or all possible values (or even selecting them) for regions, similar to how a project with CDKTF does. Additionally, you could create a tool that guides users through filling in the required parameters and then generates customized documentation with those parameters. This would make the documentation even more user-friendly.
I spent a significant amount of time waiting for redeployments. The main branch was broken due to an outdated Terraform provider, and the development branch was also not functional. If I hadn't been desperate for a solution, I might have continued searching for an alternative.
It's unfortunate when a project's main branch can become broken due to an external dependency. I assume this was not the case from the beginning. Tools like Nix can resolve such issues, but I've had difficulty getting projects like bitte up and running. Please consider addressing these concerns to enhance the user experience.
My script:
#!/bin/bash
set -e -x
instance_name="devtwo"
dir_path="hashistack/inventories/hs_${instance_name}"
if [ -d "$dir_path" ]; then
(cd "$dir_path" && source ~/.bashrc && direnv allow . && eval "$(direnv export bash)" && make scaleway_destroy)
fi
apt-get update && apt-get install git make sudo -y
rm -rf hashistack
git clone https://github.com/wescale/hashistack.git
cd hashistack
git checkout dev
cp ./../.env.secrets .env.secrets
make install-requirements
source ~/.bashrc && direnv allow .
eval "$(direnv export bash)"
make prepare
make init_instance name="${instance_name}" parent_domain=example.link archi=mono
cd "inventories/hs_${instance_name}"
make stage_0_scaleway stage_1_auto_prerequisites stage_2 stage_3
cat group_vars/hashistack/secrets/root_nomad.yml
Thanks a lot for this tale. It's gold for us.
main
branch.Beginning to have some users is surely something that will force us into a more clean way of managing branch freshness.
I cannot ssh to a newly created instance with default.key. SSHing as "caretaker" works.
Provider: scaleway archi: mono HEAD SHA: 10e48969983ba55720dc767b5aa69874938bb165 Logs: root@scw-vigorous-kowalevski:~/dev/hashistack/inventories/hs_devone/group_vars/hashistack/secrets# ssh -i default.key -v root@163.172.*.* OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for debug1: Connecting to 163.172.. [163.172..] port 22. debug1: Connection established. debug1: identity file default.key type 3 debug1: identity file default.key-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5+deb11u1 debug1: compat_banner: match: OpenSSH_8.4p1 Debian-5+deb11u1 pat OpenSSH compat 0x04000000 debug1: Authenticating to 163.172..:22 as 'root' debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:GNLadCqPfrlhpj8wBwsTHIK5Fuw34algxis64bcxxzY
debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '163.172. .**' is known and matches the ED25519 host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: default.key ED25519 SHA256:az+kPqAgiAPvEJrZMzON5UxV5izWAWkJt0HINBFdpAI explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: default.key ED25519 SHA256:az+kPqAgiAPvEJrZMzON5UxV5izWAWkJt0HINBFdpAI explicit
debug1: Server accepts key: default.key ED25519 SHA256:az+kPqAgiAPvEJrZMzON5UxV5izWAWkJt0HINBFdpAI explicit
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
root@163.172.*.'s password: