|
I'm trying to migrate from docker-compose to docker swarm, and its not going well lmao The lack of network_mode and container names makes routing traffic through my vpn node way more difficult
|
#
?
Apr 18, 2022 16:46
|
|
|
|
| # ? Jun 8, 2024 17:51 |
|
|
Just switch to k8s, ezpz.
|
|
#
?
Apr 18, 2022 18:02
|
|
|
RFC2324 posted:I'm trying to migrate from docker-compose to docker swarm, and its not going well lmao Can you expand a bit on what you're trying to do? My experience is that most of the few things from compose that aren't supported in swarm are stuff that doesn't make sense in a distributed system, and both host mode networking and individually-named instances definitely fall under that category.
|
|
#
?
Apr 18, 2022 19:09
|
|
|
NihilCredo posted:Can you expand a bit on what you're trying to do? My experience is that most of the few things from compose that aren't supported in swarm are stuff that doesn't make sense in a distributed system, and both host mode networking and individually-named instances definitely fall under that category. they absolutely do, and my complaint is more having to figure poo poo out than it is that stuff is different I'm running one container that holds a VPN. It can't be part of the swarm because it refuses to connect if it is. I currently run about half my containers through it using network_mode: <container>, but want to move those to a swarm so I can start load balancing them on an rpi cluster instead of the dying laptop they live on now. I have several compose.yml files to make this all a bit easier to manage. I know I need to create an overlay network, and attach the VPN container to it, and I *think* I managed to get that done with: code:code:code:should get the container on the vpn, but it remains unreachable while the containers that aren't in the section I moved to the swarm remain able to connect to the vpn, and thus be reachable. its a dumb routing issue, at the end of the day
|
|
#
?
Apr 18, 2022 20:48
|
|
|
RFC2324 posted:add the same 'networks: definition' in the container for the clients that get routed, plus If I read your post correctly, I think the bolded part is what's wrong. You only define the network in one place (or create it manually with docker network create), then other containers who want to attach to it only need an empty 'definition' with external: true, so that it doesn´t create a new network and instead looks for an existing one in the swarm with the correct name (stack deployment will fail otherwise). The code fragment I quoted above should be correct and sufficient by itself, assuming that the VPN was created from a file named docker-compose.yml and with no custom stack prefix. There's nothing stopping two different stacks from both having a network named 'vpn', so I think your setup is actually creating two unrelated networks both named 'vpn' but with different prefixes? If all your files are named docker-compose.yml, that might be why you get a mangled name instead - but if you used docker stack deploy you should have had to provide a name for the stack. Another thing, you want the network to have the attachable: true flag, which allows you to connect non-swarm containers to it (or something like that). It's a flag that I always enable because you never know when you might want to spin up a quick CLI container in the network to run diagnostics, and you can´t change the flag after creation. Even if that's not the source of your problems, it will make figuring things out a lot easier.
|
|
#
?
Apr 19, 2022 12:23
|
|
|
I'm referencing the network as docker-compose_vpn everywhere outside the compose file, which isn't using the docker-compose.yml standard name. I have a handful of them. The vpn container is being started by docker compose, but on a swarm node, so is scheduled as single node. I'm not sure if that is screwing with things. Ill give your approach a shot, but the only real change I am seeing is not telling the individual container to attach to the network, and the attachable: directive. Thanks for the leads!
|
|
#
?
Apr 19, 2022 18:12
|
|
|
I figured out a lot of my trouble with nvidia driver hell. The Kubuntu setup I'm on really has nouveau integrated. I haven't checked, but I wouldn't be surprised if I found out it's built into the kernel or something. I tried modifying grub configurations to disable nouveau from loading, but I eventually had to manually enter it when booting. I got dead-set on removing nouveau and using the proprietary driver because on 22.04, the screens would keep coming up crossed and the mouse clicks would register on the opposite screen from the cursor. Then it would arbitrarily crash and restart the session with all my stuff wiped. I couldn't get around nouveau with the normal modprobe.d blacklist. Removing the xorg-xserver-nouveau package was insufficient. Installing the nvidia driver packages wouldn't do it. Heck, Nvidia's own stuff wouldn't install because nouveau was already running. That's what compelled me blacklisting from the grub command line. After doing that, I got it to install and didn't have screen issues... yet. I don't know what will happen on the next boot. What I have figured out though from last time is that every new kernel package installed loses the nvidia proprietary drivers--or rather simply just comes without it, and I have to reinstall. I didn't realize this and wondered why every kernel update would brick me. So I figured out how to hold kernel packages so I can do these updates when I'm good and ready.
|
|
#
?
Apr 20, 2022 05:20
|
|
|
Is DKMS broken or something?
|
|
#
?
Apr 20, 2022 05:53
|
|
|
BrainDance posted:Is DKMS broken or something? I couldn't say if it's fundamentally broken but I sure as hell was making sure the dkms packages were also getting installed, and it wasn't changing anything. Edit: I saw in the output when those packages installed that it was running update-initramfs but nothing seemed to change. Um, yes, I did reboot. :p
|
|
#
?
Apr 20, 2022 06:58
|
|
|
So, it seems I got some stability issues with KDE, triggered by (of course) Bluetooth. Basically my BT earphones occasionally connect as 'headset' mode (two-way, lovely quality) and neither the built-in panel nor PAVU let me switch them to A2DP headphone mode. Until I figure out how to do that, I just disconnect/reconnect them a bunch of times until they hit the right mode. But when I do that, often, KDE (X11 + Nvidia drivers) starts semi-crashing - GUI apps still work, perhaps thanks to the compositor being off, but the taskbar disappears and keyboard shortcuts to launch stuff don't work anymore, Alt+f2 incuded. Here's my question: I thought I could use the standard Linux VTs to 'reset' the KDE sessions. So ctrl-alt-f3, login, then I tried first the 'nice' kquitapp5 plasmashell then the forced killall plasmashell, expecting that the "f2" default session would get dumped back to the terminal and I could then run kstart5 plasmashell. But that didn't work at all, the "f2" session remained active in its semi-broken state. Did I misunderstand something about how Linux VTs work? Are terminal sessions isolated from each other?
|
|
#
?
Apr 20, 2022 09:07
|
|
|
NihilCredo posted:So, it seems I got some stability issues with KDE, triggered by (of course) Bluetooth. Basically my BT earphones occasionally connect as 'headset' mode (two-way, lovely quality) and neither the built-in panel nor PAVU let me switch them to A2DP headphone mode. No idea what OS you use but consider switching to PipeWire if it's an option. Using BT headphones was always a shitshow with PulseAudio in my experience which sounds a lot like yours, refusing to use A2DP unless you disconnect and reconnect a few dozen times. PipeWire OTOH has just worked for the couple of years I've used it, and high quality codecs like LDAC just work without having required any effort from my side. Don't know anything about KDE.
|
|
#
?
Apr 20, 2022 09:47
|
|
|
Keito posted:No idea what OS you use but consider switching to PipeWire if it's an option. Using BT headphones was always a shitshow with PulseAudio in my experience which sounds a lot like yours, refusing to use A2DP unless you disconnect and reconnect a few dozen times. PipeWire OTOH has just worked for the couple of years I've used it, and high quality codecs like LDAC just work without having required any effort from my side. It's Fedora 35 with pipewire, which is probably why it even works 98% of the time  However the BT chip is a crap Broadcom one for which it took me quite a bit of effort to find and package the correct binaries.The previous time I had used desktop Linux was on Ubuntu 14 or so and I gave up on bluetooth headphones very quickly.
|
|
#
?
Apr 20, 2022 11:19
|
|
|
Rocko Bonaparte posted:I haven't checked, but I wouldn't be surprised if I found out it's built into the kernel or something. I tried modifying grub configurations to disable nouveau from loading, but I eventually had to manually enter it when booting.
|
|
#
?
Apr 20, 2022 14:23
|
|
|
ExcessBLarg! posted:I haven't used Nvidia hardware in decades, but if I had to guess the nouveau driver is probably mostly implemented in the drm subsystem and the module is loaded during early boot when Linux switches away from the EFI frame buffer. Purging xorg-xserver-nouveau probably doesn't help here if nouveau just works with the modesetting driver. I would try adding it to the modprobe.d blacklist and running an "update-initramfs -u" to make sure the blacklist is updated in the initramfs. Not sure what's up with DKMS though. Blacklisting in modprobe.d is what's supposed to work. It's by far the main recommendation, but it just wouldn't. The second level was to disable it as parameters to grub in /etc/default/grub (I think that's the path; I don't have the notes here). That didn't work either. However, what I didn't do: 1. Try it in the grub.cfg in /boot directly instead of relying on the default file. 2. Inspected that the arguments where on the command line before booting. I do know manually disabling it on the command line did work though.
|
|
#
?
Apr 20, 2022 16:12
|
|
|
Did you check in grub.cfg after changing the grub defaults file and regenerating grub.cfg? It should be reflected in there somewhere, and if not you can try to figure out why without having to reboot for every attempt.
|
|
#
?
Apr 20, 2022 16:33
|
|
|
I didn't check the grub.cfg while I was screwing around with it. I can say that right now it doesn't have it, and I'll infer grub.cfg didn't have those settings when I booted into this yesterday because I had to manually input it. However, that may have been after cleaning it out since the original attempts didn't work. At this point, I'm enjoying this current boot of it and will probably end up fighting this fight again next time I have to boot. But as it stands, I have a work day to do with this and hope I can just keep the environment. But yeah, I'm going in better armed this time and I at least know what's up versus the God-knows-what I did when I was first working with this environment a few months ago.
|
|
#
?
Apr 20, 2022 16:40
|
|
|
NihilCredo posted:So, it seems I got some stability issues with KDE, triggered by (of course) Bluetooth. Basically my BT earphones occasionally connect as 'headset' mode (two-way, lovely quality) and neither the built-in panel nor PAVU let me switch them to A2DP headphone mode. Ctrl-alt-backspace should restart the x session without doing silly poo poo like killall, and if that doesn't work bring it down to multi-user.target and then back up to graphical.target. The problem with trying poo poo like killall is that you probably are missing something that isn't running in the same process tree as the rest of your session. A modern GUI is a very complicated place with a shitton of interconnected processes, and coming at it with a mallet is more likely to break it than fix it. At a guess you have something launching in your init script that is hanging, and killing stuff off isn't re-running your init script.
|
|
#
?
Apr 20, 2022 16:51
|
|
|
Rocko Bonaparte posted:Blacklisting in modprobe.d is what's supposed to work. It's by far the main recommendation, but it just wouldn't. If you want to see, run "sudo unmkinitramfs /boot/initrd.img /tmp/initrd; sudo ls /tmp/initrd/main/etc/modprobe.d" and you'll see there's a bunch of module blacklists that are applied during early boot, but these only get updated from the configuration in /etc when you update the initramfs. Rocko Bonaparte posted:The second level was to disable it as parameters to grub in /etc/default/grub (I think that's the path; I don't have the notes here). That didn't work either.
|
|
#
?
Apr 20, 2022 17:22
|
|
|
RFC2324 posted:Ctrl-alt-backspace should restart the x session without doing silly poo poo like killall, and if that doesn't work bring it down to multi-user.target and then back up to graphical.target. pre:Section "ServerFlags"
Option "DontZap" "false"
EndSection
Section "InputClass"
Identifier "Keyboard Defaults"
MatchIsKeyboard "yes"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection
|
|
#
?
Apr 20, 2022 17:37
|
|
|
BlankSystemDaemon posted:^MBackspace needs this: P sure that's default in linux? I've honestly not used it in years other than a brief, but enjoyable, foray into i3 last year. I have been doing it by bouncing services for a long time.
|
|
#
?
Apr 20, 2022 17:43
|
|
|
RFC2324 posted:P sure that's default in linux?
|
|
#
?
Apr 20, 2022 18:15
|
|
|
I never knew that shortcut so that's cool to know
|
|
#
?
Apr 20, 2022 18:44
|
|
|
That's how we forced a config reload in the bad old days when WM's hadn't figured out live reloading yet.
|
|
#
?
Apr 20, 2022 18:54
|
|
|
xzzy posted:That's how we forced a config reload in the bad old days when WM's hadn't figured out live reloading yet. Which is why I had to remember it exists when I was playing with i3 lol Its useful to know occasionally, but pretty rare that its useful in 2022
|
|
#
?
Apr 20, 2022 19:14
|
|
|
ExcessBLarg! posted:Yes, if you run "sudo update-initramfs -u". I was propelled by pure rage at that point, but I swear up and down I was running update-initramfs -u along with update-grub, but that check is something I didn't know about. So between seeing the grub command line when I boot and that, I can see how I was actually flailing (failing) around last night.
|
|
#
?
Apr 20, 2022 19:31
|
|
|
We're moving to Ubuntu from CentOS I guess I don't bother getting Redhat certified now? What say you
|
|
#
?
Apr 20, 2022 19:44
|
|
|
Bob Morales posted:We're moving to Ubuntu from CentOS Is the certification important in your line of work? The...concept of it, not necessarily this one. If it is, then why wouldn't you, if you can get someone else to pay?
|
|
#
?
Apr 20, 2022 19:59
|
|
|
Volguus posted:Is the certification important in your line of work? The...concept of it, not necessarily this one. If it is, then why wouldn't you, if you can get someone else to pay? It would be helpful to have. I'm a contractor so I would have to pay it myself.
|
|
#
?
Apr 20, 2022 22:38
|
|
|
NihilCredo posted:So, it seems I got some stability issues with KDE, triggered by (of course) Bluetooth. Basically my BT earphones occasionally connect as 'headset' mode (two-way, lovely quality) and neither the built-in panel nor PAVU let me switch them to A2DP headphone mode. I have this happen on the machine I am currently using, but it happens without anything connected to Bluetooth. When I notice it has happened I usually open Konsole and logout, then log back in, and it's fine. From what I've seen it seems to happen sometimes when I am playing a video in Firefox private window, but can't say for sure because sometimes it takes me a while to realize I've lost my taskbar. As a point of reference, this machine is a desktop with a Phenom II processor, running KDE on OpenSUSE 15.3, using the proprietary Nvidia drivers on a 1060 6GB, and with an ASUS PCIe card with Intel wifi/Bluetooth. Bluetooth is active but almost never, ever connected to anything.
|
|
#
?
Apr 20, 2022 22:53
|
|
|
Bob Morales posted:We're moving to Ubuntu from CentOS
|
|
#
?
Apr 21, 2022 01:22
|
|
|
No, I'm sorry, they're moving to Ubuntu. 
|
|
#
?
Apr 21, 2022 03:59
|
|
|
We miiight go to Suse
|
|
#
?
Apr 21, 2022 22:57
|
|
|
Bob Morales posted:We miiight go to Suse objectively a good choice. yast2 is amazing and can be used as an automation tool too
|
|
#
?
Apr 21, 2022 23:50
|
|
|
Upgraded my box to the latest Ubuntu and everything went without a hitch. However, somehow my Debian VM refuses to boot now I've tried - Debian installer, advanced - recover - re-install grub and update-grub. Seems like it works okay as it doesn't spit out any errors - rescatux.iso just hangs - Armed with boot-repair-disk-64bit.iso and did full purge of grub and re-instlal, no dice - tried discarding the VM and creating it from scratch with the old disk, no dice It's a VM with default sane options, the disk is WD SN520 that hasn't reported any SMART issues. The only change is that during reboots my HW tried to boot from the disk and it failed. Quick reboot and checking the BIOS boot order and I was back in my host Ubuntu. My other VMs with similar setup (with Windows) work just fine. I'm copying the offending disk to raw disk so I can backup it and play with it with out risking data now. What should I try next? The error screen just says Grub loadingRead Error No error codes or anything. Super frustrating to google.
|
|
#
?
Apr 24, 2022 13:13
|
|
|
Sounds like a device name changed during boot up. Make sure the drive reference is pointed to a uuid, and not like, /dev/vd3
|
|
#
?
Apr 24, 2022 16:46
|
|
|
How can a device name change during boot up?
|
|
#
?
Apr 24, 2022 16:49
|
|
|
BlankSystemDaemon posted:How can a device name change during boot up? The device name changed during the upgrade, and the grub config points to the wrong name. If seen it happen, but thinking about it, i see some holes in it applying here Also during initrd handoff
|
|
#
?
Apr 24, 2022 17:01
|
|
|
Well, I got it to work by dd'ing the whole disk to a image file and using that to boot. I'll try to dd that to the offending disk and see if it magically makes it work, or investigate if it's actual bug somewhere. I'm using sane default BIOS Q35 KVM settings, nothing special other than the PCIe passthru for the disk.
|
|
#
?
Apr 24, 2022 17:08
|
|
|
RFC2324 posted:The device name changed during the upgrade, and the grub config points to the wrong name.
|
|
#
?
Apr 24, 2022 17:24
|
|
|
|
| # ? Jun 8, 2024 17:51 |
|
|
Considering it is a single drive single disk environment within KVM I could just bypass grub and use the Kernel boot option in Virt Manager?
|
|
#
?
Apr 24, 2022 17:38
|
|