Closed pythoninthegrass closed 1 month ago
Ditto the docker network:
[STDERR] Error response from daemon: network with name sidekick already exists
panic: error running command - sudo docker network create sidekick: - Error response from daemon: network with name sidekick already exists
FWIW these are the steps needed to fix them manually after logging in as another user with sudo privileges:
sudo -s
systemctl stop nginx
systemctl disable nginx
sed -i 's/PermitRootLogin no/PermitRootLogin yes/' /etc/ssh/sshd_config
systemctl restart ssh
cd /home/sidekick
docker compose -f docker-compose.traefik.yml down --remove-orphans
userdel sidekick
rm -rf /home/sidekick
docker network rm sidekick
And finally I'm left with this error:
[STDERR] Container sidekick-traefik-service-1 Starting
panic: error running command - cd sidekick-traefik && sudo docker compose -p sidekick -f docker-compose.traefik.yml up -d: - Container sidekick-traefik-service-1 Starting
goroutine 1 [running]:
github.com/mightymoud/sidekick/cmd.init.func4(0x140001ec900?, {0x104cdd572?, 0x4?, 0x104cdd576?})
/Users/lance/git/sidekick/cmd/init.go:191 +0x1bec
github.com/spf13/cobra.(*Command).execute(0x10515acc0, {0x1051c78e0, 0x0, 0x0})
/Users/lance/.asdf/shims/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:989 +0x828
github.com/spf13/cobra.(*Command).ExecuteC(0x10515b560)
/Users/lance/.asdf/shims/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1117 +0x344
github.com/spf13/cobra.(*Command).Execute(...)
/Users/lance/.asdf/shims/pkg/mod/github.com/spf13/cobra@v1.8.1/command.go:1041
github.com/mightymoud/sidekick/cmd.Execute()
/Users/lance/git/sidekick/cmd/root.go:36 +0x24
main.main()
/Users/lance/git/sidekick/main.go:20 +0x1c
exit status 2
It'd probably be easier to rename the compose file to docker-compose.yml
; then the -f
flag wouldn't be necessary. Not sure why it's got a non-standard name if there aren't multiple files in the repo/directory.
Firstly thanks for your kind words. Sidekick is my firs work on OSS and I'm enjoying it so far thanks to contributors like you.
Now all those points you bring up are good points. Let's take them one by one
I'm confident in my linux/dev abilities to fix all the above, but honestly, the error should've been handled in the business logic already.
I agree with this. I usually just smash the VPS and try again. I have tried with lots and lots of IPs LOL. In your case I understand that is not possible. I wanna make sure to highlight this: Sidekick was not meant to help with homelabs. I'm happy it does help, but I honestly never thought about it being like a solid option for homelabs.
Now let's take a step back; why did the command fail in the first place? we need to tackle that before we fix the logic to make more smarter - which we should indeed.
I think what we can do is just add like an if check before each step. But like I said, I wanna know why did it fail first? Then we can tackle the root issue, then we can improve the logic here.
Also wanna say this now that someone else is seeing the error reporting in Sidekick - I'm not proud of it at all. It is on my task list to make it better. We need to transport the last error message from the VPS then display it properly and remove all those panic statements showing the trace and all that. All that needs a clean up...
The error for you is coming from line 191 on init.go
but you said you changed things. So I don't know where the issue came from
/cmd/init.go:191
It'd probably be easier to rename the compose file to docker-compose.yml; then the -f flag wouldn't be necessary. Not sure why it's got a non-standard name if there aren't multiple files in the repo/directory.
Finally yeah I was thinking to make it all in one folder with multiple docker compose files, but ended up thinking it was too messy. Will change that maybe in the release after the one I am doing today.
Thanks for all the feedback and discussions. Let's keep the convo going
I think there would be a lot of value in supporting long-lived servers. There's a lot of tooling to work with disposable servers but not so much for traditional bare metal and other such situations, and Sidekick fits that niche well.
Totally makes sense. Gonna be some rough edges before the release candidate.
VPSes are where I got my start back in the wordpress days, but I usually do most of my dev work on bare metal homelabs. Then push out the production server to a VPS or hyperscaler.
For hobby projects, I'd like to avoid the hosting fees altogether with the caveat that now security and high availability are my responsibility. I'm okay with that if it saves me at least $100/year.
That's why I think sidekick fills a need that isn't covered by traditional VPSes or the major clouds -- it's now possible to avoid a lot of the toil involved with deployments (permissions, reverse proxy, etc.) with the added bonus of being host agnostic.
To me, this satisfies less complex deployments than 37signals' kamal.
From: Louis Pilfold @.> Sent: Tuesday, September 24, 2024 8:34:52 AM To: MightyMoud/sidekick @.> Cc: pythoninthegrass @.>; Author @.> Subject: Re: [MightyMoud/sidekick] fix: Idempotency (Issue #20)
I think there would be a lot of value in supporting long-lived servers. There's a lot of tooling to work with disposable servers but not so much for traditional bare metal and other such situations, and Sidekick fits that niche well.
— Reply to this email directly, view it on GitHubhttps://github.com/MightyMoud/sidekick/issues/20#issuecomment-2371295056, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA7ILPZAX3O67JI5TLY2DQTZYFS7ZAVCNFSM6AAAAABOXHIMQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZRGI4TKMBVGY. You are receiving this because you authored the thread.Message ID: @.***>
Yeah I don't see any problems to make sure Sidekick works for homelabs and long running servers as long as we keep the same simplicity and ergonomics intact. It just that I never thought of that when developing the idea to start with. This will make Sidekick better overall regardless, so I'm keen. Now we are all on the same page, we need the following:
So if you are keen @pythoninthegrass are you able to pick one and let me know? I will be doing more work on the other throughout the week.
Absolutely! I can take the idempotency refactoring. Be a good opportunity to brush up on go and its infamous error handling haha.
From: Mahmoud Mousa @.> Sent: Wednesday, September 25, 2024 3:31:33 AM To: MightyMoud/sidekick @.> Cc: pythoninthegrass @.>; Mention @.> Subject: Re: [MightyMoud/sidekick] fix: Idempotency (Issue #20)
Yeah I don't see any problems to make sure Sidekick works for homelabs and long running servers as long as we keep the same simplicity and ergonomics intact. It just that I never thought of that when developing the idea to start with. This will make Sidekick better overall regardless, so I'm keen. Now we are all on the same page, we need the following:
So if you are keen @pythoninthegrasshttps://github.com/pythoninthegrass are you able to pick one and let me know? I will be doing more work on the other throughout the week.
— Reply to this email directly, view it on GitHubhttps://github.com/MightyMoud/sidekick/issues/20#issuecomment-2373419008, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA7ILPYYJMJEHVS7LOH2QMDZYJYGLAVCNFSM6AAAAABOXHIMQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZTGQYTSMBQHA. You are receiving this because you were mentioned.Message ID: @.***>
Alright this is now fixed with the release just now. v0.6.3
You can run init as many times as you want now on same server.
If it fails, you can just restart it and try again.
Also if you try to run init with another server address, Sidekick will prompt you to confirm. You can disable this by passing -y
flag when running init
Cheers
Outstanding!! I'll give it a go.
Thanks @MightyMoud !
First, wanna make sure you know I really appreciate what you're doing here. OSS is oftentimes a thankless vacuum and it can be really frustrating at times. So kudos to you @MightyMoud!
Was able to figure out what's going on with the SSH connection to my Ubuntu box. macOS doesn't really use the SSH agent (that I'm aware of) like *nix distros.
Refactored quite a few of the cmd and utils scripts to read the .env file of my private key successfully.
However, ran into some other gotchas where
I'm confident in my linux/dev abilities to fix all the above, but honestly, the error should've been handled in the business logic already.
The alternative is blowing away the vm and starting from scratch which is trivial on VPSes but a bit of a pain in a homelab environment (although a type 1 hypervisor and cloud-init helps!).
I say all that to give constructive feedback. I like the project and it's novel approach to real world problems. Know we all have blind spots and end users' environments can differ quite a bit.
Happy to help QA 🤙