glizzyguzzler

joined 1 year ago
[–] [email protected] 2 points 1 day ago

Sad to hear for my quadlet future, do you remember what things were specifically annoying?

[–] [email protected] 10 points 1 day ago* (last edited 1 day ago) (2 children)

Hey bigdickdonkey, I recently tried and wasn’t able to shit my way through podman, there just wasn’t enough chatter and guides about it. I plan to revisit it when Debian 13 comes out, which will include podman quadlets. I also tried to get podman quadlets to work on Ubuntu 24 and got closer, but still didn’t manage and Ubuntu is squicky.

I read about true user rootless Docker and decided that was too finicky to keep up to date. It needs some annoying stuff to update, from what I could tell. I was planning on many users having their own containers, and that would have gotten annoying to manage. Maybe a single user would be an OK burden.

The podman people make a good argument for running podman as root and using userns to divvy out UIDs to achieve rootless https://www.redhat.com/en/blog/rootless-podman-user-namespace-modes but since podman is on the back burner till there’s more community and Debian 13, I applied that idea to Docker.

So I went with root Docker with the goals of:

  • read only
  • set user to different UID:GID for each container
  • silo containers in individual Docker networks
  • nothing gets /var/run/docker.sock
  • cap_drop: all
  • security-opt=no-new-privileges
  • volumes all get tagged with :rw,noexec,nosuid,nodev,Z

Basically it’s the security best practices from this list https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html

This still has risk of the Docker daemon being hacked from the container itself somehow, which podman eliminates, but it’s as close to the podman ideal I can get within my knowledge now.

Most things will run as rootless+read-only+cap_drop with minor messing. Automatic ripping machine would not, but that project is a wild ride of required permissions. Everything else has succumbed, but I’ve needed to sometimes have a “pre launch container” to do permission changes or make somewhere like /opt writable.

I would transition one app stack at a time to the best security practices, and it’s easier since you don’t need to change container managers. Hope this helps!

[–] [email protected] 38 points 2 months ago

Sounds like your freezer isn’t actually getting cold enough for the ice cream. Semi-melted Tilamook will get whipped-esque if not cold enough. Put a digital thermometer in there for a while and see what temp it’s holding! No ice cream is “drop metal into it and it slides to the bottom” unless it’s not cold enough

As for ice cream consistency, afaik more cream content (which is better ice cream) will be softer at the same temperature compared to ice cream with more water content (shit ice cream). Breyers regular (I think they have a fancy attempt with more cream) is pretty watery, Tilamook is creamed up

(Do you notice a lot of frost on stuff? That is a sign of a bad seal and (humid) air is getting in)

[–] [email protected] 2 points 3 months ago

Tiger, you’re very similar to many of the semiconductor EEs I know :) and I mean that in a teasing-but-you-know-cause-you-work-in-the-industry way. Yeah, we only really care about whiskering in the context of electrical devices. That’s what it’s saying. Read the “Mechanics” section, it tells you nothing about actual electromigration doing it; they describe an E field encouraging metal ions in a fluid to make a reaching whisker and link to electromigration because it technically is “electromigration” making the targeted whisker occur. But IC-style electromigration is not causing the whisker, clearly cause no currents are flowing, which is why I took the time to write the explanation in the first place.

But just because the semiconductor community called it whiskers so it shares the name with the Big Whiskers, does not make the process anywhere close to similar. The current densities that cause absolutely not present for the stress ones, which the wiki article is about.

[–] [email protected] 6 points 3 months ago (3 children)

Tiger I think you're being pedantic, they linked to Whiskers (metallurgy) not Whiskers (electromigration). There is a difference! But it's not super clear cut, which is why I took the time to write about it.

Electrons do not always move at the same speed in a given metal. A lot of things affects mobility, but the E field is very important too. Both things combine so that electrons do not always move at the same speed in a given metal. But you can simplify in an IC world because there you're riding the saturation velocity basically always, which is why I assume you keep claiming that.

I want you to know that your experiences from your education and job are valid - you do deal with whiskers in ICs, not denying that; the fact is that whiskers due to stresses and strains aren't called electromigration which is what the original comment says.

"A similar thing also called whiskers can happen inside ICs and has been a known failure mode for high frequency processors for many years. I work in chip design, and we use software tools to simulate it. It’s due to electromigration and doesn't rely on stresses but instead high current densities."

[–] [email protected] 2 points 3 months ago

Check out https://en.wikipedia.org/wiki/Hot-carrier_injection hot carrier degredation, it's in the vicinity of electron mobility but in a semiconductor setting. Key link is it's electrons with momentum doing the work. In this case electrons (much hotter than in electron mobility, which are limited by the saturation velocity) smash into the gate dielectric, making it a worse dielectric. Hot carrier injection doesn't have to end in damage to the dielectric, but when it does it's hot carrier degredation. There's a lot going on though, semiconductors are really complex - like electron tunneling also exists.

[–] [email protected] 6 points 3 months ago* (last edited 3 months ago) (5 children)

The metal moves due to very different reasons. I would not say whiskers due to mechanical/residual stresses are due to "electromigration" - electromigration isn't even there since the wiki definition is "transport of material caused by the gradual movement of the ions in a conductor due to the momentum transfer between conducting electrons and diffusing metal atoms". You build stresses and strains into semiconductors for better mobility profiles, and I'm sure that can cause whiskers - but again, it's not electromigration.

Electromigration, as noted, plays a role in the form of encouraging stress whiskers to grow in a direction (with a very relaxed definition).

But in ICs, with their very unique extremely small scales, electromigration can directly form whiskers by moving individual ions via electron collisions. But the generation mechanism for those whiskers shares nothing with Big Whiskers generation mechanism. That's my point.

Electrons in metal do not always move at the same speed; they move at v=mu*E where v is the velocity, mu is the electron mobility, and E is the electric field. Crank the E, you go faster. At very high E fields you reach the electron saturation velocity where slowing factors limit the maximum speed - I assume in your IC world you're basically always there due to the extremely small regions (E = V/m; any V with m at nanometers is big E) which is why you claim that. But even then the electrons are accelerating due to the E field, smashing into ions and losing their momentum (mass static, so it's just velocity), and then re-accelerating. The saturation velocity is the average bulk motion of electrons but it's not a smooth highway, it's LA traffic (constant crashes).

Electrons can gain significant momentum, which is just their static mass times their velocity. Limited at velocity by the saturation velocity, current density is important for significant momentum exchange. Luckily ICs are so tiny that the currents they drive are massive current densities.

What you said originally is correct; it's just in ICs electromigration can cause whiskers. In the Big World it can't. But it can influence Big Whiskers to grow to the worst places and fuck up things optimally if you take an extremely relaxed view of electromigration that defines it as "movement of ions encouraged by an electric field".

[–] [email protected] 23 points 3 months ago (7 children)

This statement is not fully accurate. Whiskers in OP’s case are about (usually) tin whiskers that grow, often visibly, and then can connect (short) to unintended areas.

Electromigration is effectively when a large potential difference encourages ions to relocate to reduce the potential difference.

Big Whiskers have two methods of formation. The first way is that tin ions are able to move by becoming soluble in some form of water so they’re mobile. The other way whiskers can form is from stress alone. (Stress being force per area that compresses or tensions the metal in question, applied through a multitude of ways) Whiskers can be directed by electromigration so they form tendrils to a differing potential, basically purposefully ruining stuff instead of randomly shorting things.

Now in integrated circuits (ICs), there are extremely high currents running through extremely small regions. Electromigration in ICs is caused by electrons getting yeeted at extremely fast speeds, giving them significant momentum. They collide with ions in their path and dislodge the ions from their matrix. This can result in voids of ions preventing current from flowing (open circuits) or tendrils of ions making a path to an unintended area and connecting to it (shorting it). The tendrils here are also called whiskers, but are generated in a very different way (e.g., no water solubility or inherent stresses required) and on a significantly smaller scale. And probably not in tin.

The more you know!

[–] [email protected] 1 points 4 months ago

Mine clicked just after a year :( so it’s waiting to get switches soldered cause I ain’t buying a new one but don’t have the will to do it yet cause I got my ancient G5 still. (I live in America, so doing warranty shit is a hassle, and I surmised it would fail again so I should just fix it now)

[–] [email protected] 2 points 4 months ago (2 children)

That’s what I mean, even e-waste quality razer isn’t double clicking!!

[–] [email protected] 2 points 4 months ago (1 children)

I had to replace the cable on my G5 after it frayed after about a decade, but after that it was back to it. Sorry you lost yours, and I hope you never double click on the G502!

(All the weights gang, build that wrist strength)

[–] [email protected] 3 points 4 months ago (3 children)

Mine is a G5, which looks like it lost the MX518’s sick ass faux metal and instead gets what I can best call “cracked lightning?”. I was too young to figure out mouse buying so the fam’s resident nerd chose that for me - I thank her to this day

 

Edit: Results tabulated, thanks for all y'alls input!

Results fitting within the listed categories

Just do it live

Shut down all database containers

Long-ass backup script

Mythical database live snapshot command

(it seems pg_dumpall for Postgres and mysqldump for mysql (though some images with mysql don't have that command for meeeeee))

Docker image that includes Mythical database live snapshot command (Postgres only)

New catagories

Snapshot it, seems to act like a power outage to the database

  • LVM snapshot -> backup that @[email protected]

  • ZFS snapshot -> backup that @[email protected] (real world recovery experience shows that databases act like they're recovering from a power outage and it works)

  • (I assume btrfs snapshot will also work)

One liner self-contained command for crontab

  • One-liner crontab that prunes to maintain 7 backups, dump Postgres via pg_dumpall, zips, then rclone them @[email protected]

Turns out Borgmatic has database hooks

  • Borgmatic with its explicit support for databases via hooks (autorestic has hooks but it looks like you have to make database controls yourself) @[email protected]

I've searched this long and hard and I haven't really seen a good consensus that made sense. The SEO is really slowing me on this one, stuff like "restic backup database" gets me garbage.

I've got databases in docker containers in LXC containers, but that shouldn't matter (I think).

me-me about containers in containersa me-me using the mental gymnastics me-me template; the template is split into two sections with the upper being a simple 3-step gymnastic routine while the bottom has the one being mocked flipping on gymnastic bars, using gymnastic rings, a balance beam, before finally jetpacking over a burning car. The top says "docker compose up -d" in line with the 3 simple steps of the routine, while the bottom, while becoming increasingly more cluttered, says "pass uid/gid to LXC", "add storage devices to LXC", "proxy network", "install docker on every container", and finally "docker compose up -d".


I've seen:

  • Just backup the databases like everything else, they're "transactional" so it's cool
  • Some extra docker image to load in with everything else that shuts down the databases in docker so they can be backed up
  • Shut down all database containers while the backup happens
  • A long ass backup script that shuts down containers, backs them up, and then moves to the next in the script
  • Some mythical mentions of "database should have a command to do a live snapshot, git gud"

None seem turnkey except for the first, but since so many other options exist I have a feeling the first option isn't something you can rest easy with.

I'd like to minimize backup down times obviously, like what if the backup for whatever reason takes a long time? I'd denial of service myself trying to backup my service.

I'd also like to avoid a "long ass backup script" cause autorestic/borgmatic seem so nice to use. I could, but I'd be sad.

So, what do y'all do to backup docker databases with backup programs like Borg/Restic?

20
submitted 5 months ago* (last edited 5 months ago) by [email protected] to c/[email protected]
 

[Semi-solved edit]: To answer my question, I was not able to figure out podman. There's just too little community explanations about it for me to pull myself up by my own bootstraps.

So I went for Incus, which has a lot of community explanations (also via searching LXD) and made an Incus container with a macvlan and put the adguard home docker in that. Ran the docker as "root" and used docker compose since I can rely on the docker community directly, but the Incus container is not root-privileged so my goal of avoiding rootful is solved.

Anyone finding this via search, the magic sauce I needed to achieve a technically rootless adguardhome docker setup was:

sudo incus create gooner # For networking, it doesn't need to be named gooner
sudo incus profile device add gooner eth0 nic nictype=macvlan parent=enp0s10 # Get your version of 'enp0s10' via 'ip addr', macvlan thing won't work with wifi
sudo incus profile set gooner security.nesting=true
sudo incus profile set gooner security.syscalls.intercept.mknod=true
sudo incus profile set gooner security.syscalls.intercept.setxattr=true
# Pause here and make adguardhome instance in the Incus web UI (incus-ui-canonical) with the "gooner" profile
# Make sure all network stuff from docker-compose.yml is deleted
# Put docker-compose.yml in /home/${USER}/server/admin/compose/adguardhome
printf "uid $(id -u) 0\ngid $(id -g) 0" | sudo incus config set adguardhome raw.idmap - # user id -> 0 (root), user group id -> 0 (root) since debian cloud default user is root
sudo incus config device add adguardhome config disk source=/home/${USER}/server/admin/config/adguardhome path=/server/admin/config/adguardhome # These link adguard stuff to the real drive
sudo incus config device add adguardhome compose disk source=/home/${USER}/server/admin/compose/adguardhome path=/server/admin/compose/adguardhome
# !! note that the adguardhome docker-compose.yml must say "/server/configs/adguardhome/work" instead of "/home/${USER}/server/configs/adguardhome/work"
# Install docker
sudo incus exec adguardhome -- bash -c "sudo apt install -y ca-certificates curl"
sudo incus exec adguardhome -- bash -c "sudo install -m 0755 -d /etc/apt/keyrings"
sudo incus exec adguardhome -- bash -c "sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc"
sudo incus exec adguardhome -- bash -c "sudo chmod a+r /etc/apt/keyrings/docker.asc"
sudo incus exec adguardhome -- bash -c 'echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null'
sudo incus exec adguardhome -- bash -c "sudo apt update"
sudo incus exec adguardhome -- bash -c "sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin"
# Disable port 53 binding
sudo incus exec adguardhome -- bash -c "[ -d /etc/systemd/resolved.conf.d ] || mkdir -p /etc/systemd/resolved.conf.d"
sudo incus exec adguardhome -- bash -c "printf "%s\n%s\n" '[Resolve]' 'DNSStubListener=no' | sudo tee /etc/systemd/resolved.conf.d/10-make-dns-work.conf"
sudo incus exec adguardhome -- bash -c "sudo systemctl restart systemd-resolved"
# Run the docker
sudo incus exec adguardhome -- bash -c "docker compose -f /server/admin/compose/adguardhome/docker-compose.yml up -d"

I'm trying to get rootless podman to run adguard home on Debian 12. I run the docker-compose.yml file via podman-compose up -d.

I get errors that I cannot google successfully, sadly. I do occasionally see shards of people saying things like "I have adguard running with rootless podman" but never any guides. So tantalizing.

I have applied this change so rootless can yoink port 53:

sudo nano /etc/sysctl.conf

net.ipv4.ip_unprivileged_port_start=53 # at end, required for rootless podman to be able to do 53

(Do I even need that change with a macvlan?)

The sticking point seems to be the macvlan. I want a macvlan so I can host a PiHole as a redundant fallback on the same server. I error with:

Error: netavark: Netlink error: No such device (os error 19) and that error really gets me no where searching for it. I am berry sure the ethernet connection is named enp0s10 and spelled right in the docker-compose file, cause I copied and pasted it in.

I tried forcing the backend to "CNI" but probably did it wrong, it complained about:

WARN[0000] Failed to load cached network config: network dockervlan not found in CNI cache, falling back to loading network dockervlan from disk
WARN[0000] 1 error occurred:
        * plugin type="macvlan" failed (delete): cni plugin macvlan failed: Link not found

(I also made a /etc/cni/net.d/90-dockervlan.conflist file for cni but it didn't seem to see it and I couldn't muster how to get it to see it)

Both still occur if I pre-make the dockervlan with:

podman network create -d macvlan -o parent=enp0s10 --subnet 10.69.69.0/24 --gateway 10.69.69.1 --ip-range 10.69.69.69/32 dockervlan

And adjust the compose file's networks: call to:

networks:
    dockervlan:
        external: true
        name: dockervlan

Has anyone succeeded at this or done something similar?

docker-compose.yml:

version: '3.9'
#
***
NETWORKS
***
networks:
    dockervlan:
        name: dockervlan
        driver: macvlan
        driver_opts:
            parent: enp0s10
        ipam:
            config:
              - type: "host-local"
              - dst: "0.0.0.0/0"
              - subnet: "10.69.69.0/24"
                rangeStart: "10.69.69.69/32" # This range should include the ipv4_address: in services:
                rangeEnd: "10.69.69.79/32"
                gateway: "10.69.69.1"
#
***
SERVICES
***
services:
    adguardhome:
        container_name: adguardhome
        image: docker.io/adguard/adguardhome
        hostname: adguardhome
        restart: unless-stopped
        networks:
            dockervlan:
                ipv4_address: 10.69.69.69# IP address inside the defined dockervlan range
        volumes:
            - '/home/${USER}/server/configs/adguardhome/work:/opt/adguardhome/work'
            - '/home/${USER}/server/configs/adguardhome/conf:/opt/adguardhome/conf'
            #- '/home/${USER}/server/certs/example.com:/certs # optional: if you have your own SSL certs
        ports:
            - '53:53/tcp'
            - '53:53/udp'
            - '80:80/tcp'
            - '443:443/tcp'
            - '443:443/udp'
            - '3000:3000/tcp'

podman 4.3.1

podman-compose 1.0.6

Getting a newer podman-compose is pretty easy peasy, idk about newer podman if that's needed to fix this.

 

I have my home network behind a wireguard VPN connection. The wireguard "server" is run on a debian computer and the home network is handled by an opnsense computer.

Edit: opnsense does DHCP but a switch does the actual local routing, so opnsense isn't involved in 10.0.66.XXX <-> 10.0.69.XXX comms.

My home network is on the subnet 10.0.69.XXX, while the VPN connection gets the subnet 10.0.66.XXX.

Weirdly, this setup worked fine until yesterday for the PS Remote Play app (hard requirement, iOS device). Nothing changed as far as I can tell - but yesterday the PS4 stopped being found by the PS Remote Play app (when I'm home on the 10.0.69.XXX subnet, the PS Remote Play app works fine).

I suspect from what I can google ( https://www.snbforums.com/threads/ps4-remote-play-over-vpn.60629/ , https://github.com/williampiat3/ImprovingPSRemotePlay#longer-and-more-complex-solution ) that to make it seem to the PS Remote Play app that all is well abs. 100% I need to get my device on 10.0.66.10 to do a broadcast search on the 10.0.69.XXX subnet (or have a 10.0.69.XXX address).

I feel (hope) there is a way to do this, but I am no iptables wizard. Does anyone know how to accomplish this? The solutions linked don't make sense to me in a practical way to apply them.

view more: next ›