| deostroll | Do cloud based images (vmdk files) have a user profile we can log-in with? | 14:48 |
|---|---|---|
| deostroll | For e.g. https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.vmdk | 14:49 |
| tomreyn | deostroll: try #ubuntu-cloud | 15:47 |
| tomreyn | (the irc channel, not as a password ;-) ) | 15:48 |
| tomreyn | (the irc channel, not as a username / password ;-) ) | 15:48 |
| deostroll | You mean type what for username and password? | 15:52 |
| deostroll | username = ubuntu-cloud | 15:53 |
| deostroll | password = ?? | 15:53 |
| lotuspsychje | deostroll: the advice been given is to join the irc channel #ubuntu-cloud | 15:57 |
| deostroll | oh | 15:57 |
| falz | hola. lots of google hits on this and lots of rabbit holes. on a fresh ubuntu 22.x server install, stock, i gave it the nameservers i wanted to use. resolv.conf by deafult puts a local caching resolver in place (127.0.0.53) which is using this. I don't want this extra level of caching as we operate our own resolvers, this just means more places to purge cache in certain circumstances. | 16:54 |
| falz | anyone have an 'actually really clean' method for me to just put my resolvers in /etc/resolv.conf? seems to be a `resolveconf` and a `systemd` method and each maybe fight a bit. looking to K.I.S.S (disable some service, edit that file perhaps) | 16:54 |
| === sdeziel_ is now known as sdeziel | ||
| falz | I attempted to install resolvconf and update its head/tail files but no where in there does it cleanly let me remove 127.0.0.53. | 16:56 |
| sdeziel | falz: I think you need to change `/etc/resolv.conf`'s symlink to point to `/run/systemd/resolve/resolv.conf` instead of the usual `/run/systemd/resolve/stub-resolv.conf` one | 17:00 |
| falz | sdeziel: ty, I did do that. but now I'm trying to figure out what config file *IT* uses, ie how do i change my resolvers? | 17:02 |
| falz | want to fully understand wtf is happening. `resolvectl` seems to show them, but it has no actual config file I can see. | 17:02 |
| sdeziel | falz: alternatively, you can stick with the default of using systemd-resolved but simply tell it not to cache (`Cache=no`, see `man resolved.conf`) | 17:03 |
| falz | hmm. so thats still convoluted in that it still runs and points to 127.0.0.53? | 17:04 |
| sdeziel | I think adding `resolvconf` into the mix makes it harder to reason about | 17:04 |
| falz | i think you're right and i was starting there as i could add to a 'head' file and it seemed clean. but I had no way of cleanly removing that lo53 ip | 17:05 |
| sdeziel | falz: indeed, the `nameserver 127.0.0.53` bit would remain but that's for compatibility. Is there problem in having it there? | 17:05 |
| falz | ideally I want to know where nameservers are running, and thats our nameservers and not each unix hots. maybe this is some old man neckbeard yells at cloud thing. but "if it aint broke.." | 17:05 |
| falz | so I think i have two things. 1) contents of resolve.conf, which could be 127 w/o cache. 2) where are the name servers *actually configured*. I specified them in the install script, and `resolvectl` shows them | 17:06 |
| sdeziel | that's the thing, systemd-resolved has more smart when it comes to DNS routing than what can be expressed in the traditional /etc/resolv.conf | 17:07 |
| falz | i mean cool but I dont need that. servers aren't multihomed/vrf'd with NICs, etc | 17:07 |
| falz | just a server with one nic serving stuff | 17:07 |
| sdeziel | falz: then in that case you have the option of turning `/etc/resolv.conf` into an actual file (!= symlink) and put whatever content you want in it | 17:08 |
| falz | I fear some yum update will blow it away? | 17:08 |
| mdeslaur | there's a bunch of steps to disable systemd-resolved and resolvconf in one of our test scripts here, it may be of help: https://git.launchpad.net/qa-regression-testing/tree/scripts/test-dnsmasq.py#n300 | 17:08 |
| sdeziel | falz: when `/etc/resolv.conf` is an actual file, it signals systemd-resolved to stop messing with it | 17:08 |
| sdeziel | I would advise not running `yum update` on a Ubuntu machine ;) | 17:09 |
| falz | oh hah. yeah whoops, we're transitioning off of centos (finally). sorta glad they killed it. this is a part of me replciating initial server config for VM templates | 17:09 |
| falz | mdeslaur: eyes emoji goes here | 17:10 |
| znf | I would also advise to stop working "against" the way systemd does things | 17:10 |
| falz | oh yeahg netplan. is that where the resolver IPs actually go using the in-built method? | 17:10 |
| falz | znf: I'm leaning this way and now just want to know what config file my dns servers went into when I did the install wizard. netplan's yaml thing? | 17:11 |
| falz | and if so, are those the 'source' of whatever systemd-resolv is using? | 17:11 |
| mdeslaur | +1 on not disabling everything, and just using the netplan config file to specify what you want | 17:11 |
| znf | yes, it grabs the ns from netplan | 17:12 |
| falz | so it sounds like the cleanest way to do that is to just use netplan yaml, and tell 127.0.0.53 to not cache? | 17:12 |
| sdeziel | `mkdir -p /etc/systemd/resolved.conf.d/; echo -e "[Resolve]\nCache=no" > /etc/systemd/resolved.conf.d/nocache.conf; systemctl daemon-reload; systemctl restart systemd-resolved` | 17:15 |
| sdeziel | falz: this ^ should let you disable the cache without fearing for any package update undoing it | 17:16 |
| falz | .. cleanest way of doing that seems to be put something in resolvd.conf.d as its own file, probs? | 17:16 |
| sdeziel | falz: that's what the one liner does | 17:17 |
| falz | my eyes agree ty | 17:17 |
| falz | ok doing this, verifying with `resolvectl` seems to work. yay rabbitholes. | 17:22 |
| falz | ty all gentlemen/women | 17:23 |
| falz | i havent even gotten to ntp yet.. will this be the same? | 17:24 |
| sdeziel | falz: by default, netplan tells systemd-timesyncd which NTP server was advertised by DHCP so not much to configure unless you want something fancier | 17:29 |
| falz | last note about 'overly complex dns resolution'. my brain will think that theres a chance that that system level dns resolver may stop functioning for some reason and all dns will break. i say this not really knowing how dns resolution worked with only resolv.conf, other than some apps will read from it natively | 17:30 |
| falz | we don't use dhcp | 17:30 |
| falz | my method there will be to comment out the ubuntu pools and add our ntp servers manually in the existing ntp.conf, which fortunately isnt a symlink | 17:31 |
| sdeziel | falz: then you can put a `NTP=` line in `/etc/systemd/timesyncd.conf.d/<something>.conf` | 17:31 |
| sdeziel | falz: FYI, the default NTP client is systemd-timesyncd but if you want something fancier, chrony is what I'd recommend as it replaced the old ntpd | 17:32 |
| sdeziel | chrony being in main while ntpd was demoted to universe IIRC | 17:32 |
| falz | nice ty. | 17:34 |
| Odd_Bloke | Does anyone know of a standard for including git revision data in (Debian|Ubuntu) versions? I see quite a few different ways in the archive. | 19:04 |
| sergiodj | Odd_Bloke: there's no project-wide standard AFAIK, but I usually follow the Debian Golang team's guidelines: https://go-team.pages.debian.net/packaging.html#_version_numbers | 19:35 |
| Odd_Bloke | sergiodj: Thanks! | 19:42 |
| sergiodj | yw :) | 19:44 |
| rbasak | Odd_Bloke: I don't think it's exactly what you're asking, but please be aware of https://dep-team.pages.debian.net/deps/dep14/ if you're not already. Once you have a version, it's a standard for how the tag should be derived. | 20:10 |
| rbasak | (amongst other things probably less relevant to you) | 20:10 |
| Odd_Bloke | rbasak: Thanks! | 20:44 |
| === bbezak8 is now known as bbezak | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!