[00:06] <rbasak> ivo_cavalcante: AIUI there's a minimal set that will always be installed.
[00:07] <rbasak> You can add more packages, but you want to remove any (not really recommended) then you can add a command to do that I guess.
[00:08] <ivo_cavalcante> yes, I too believe this is the behavior
[00:08] <rbasak> See "late-commands" in https://ubuntu.com/server/docs/install/autoinstall-reference
[00:09] <ivo_cavalcante> was wondering if I could have a more generic installer, in order to leave the "specialization" of the device to later config manager tools
[00:09] <ivo_cavalcante> could have a single installer to desktops, bare metal servers, whatever
[00:10] <rbasak> cloud-init supports hand-off to puppet and chef
[00:10] <ivo_cavalcante> for desktops, I'll probably have to remove the 'ubuntu-server' package tha comes pre-installed
[00:10] <rbasak> The server installer isn't designed for desktops, though I suppose you can hack that in
[00:10] <ivo_cavalcante> I know, but support is kinda old, as per doc
[00:10] <ivo_cavalcante> Puppet 4, I believe
[00:11] <ivo_cavalcante> we're using 7
[00:11] <rbasak> cloud-init will also hand off to an arbitrary command, so you can do you what you like :)
[00:11] <rbasak> However any tool is going to have to start at some Ubuntu baseline, which is what the server installer gives you.
[00:11] <ivo_cavalcante> problem is that desktop installer con't be automated, can it?
[00:12] <rbasak> There's a new desktop installer in the works, but I'm guessing automation won't be in its immediate roadmap
[00:12] <rbasak> What problem are you trying to solve here?
[00:12] <ivo_cavalcante> mostly, I would need the user just to input something about network conf, since we've different confs in different places
[00:12] <ivo_cavalcante> and the rest would go by itself
[00:13] <rbasak> You're trying to use the server installer to make an automated desktop installer?
[00:14] <ivo_cavalcante> well, this is the problem: I want to have a installer with minimal input (basically network, as I said) and that could handle the job to more specalized tools, once a minimal system is installed
[00:14] <ivo_cavalcante> both desktop and server
[00:14] <ivo_cavalcante> if possible
[00:14] <rbasak> You can certainly hack something together
[00:14] <ivo_cavalcante> just need something to install base packages
[00:14] <rbasak> But I'm not sure it's a good idea to use the server installer to install a desktop
[00:15] <oerheks> rbasak, +1. the mini iso comes in mind ..
[00:15] <ivo_cavalcante> weel, it wouldn't install neither a desktop nor a server
[00:15] <ivo_cavalcante> just basic packages
[00:15] <rbasak> You'll end up with something subtly different from what the desktop installer does, and so might end up with weird issues down the line
[00:15] <ivo_cavalcante> specalizantion comes after
[00:15] <rbasak> Maybe just hack what you want with debootstrap directly?
[00:16] <ivo_cavalcante> hum
[00:16] <ivo_cavalcante> didn't look into it
[00:16] <ivo_cavalcante> want to use newer tools, if possible
[00:16] <rbasak> The desktop installer does fancy stuff like detecting when hardware needs proprietary drivers and sorting those out, etc.
[00:16] <ivo_cavalcante> I know cloud-init, using it to ceate another image, different use case
[00:17] <ivo_cavalcante> our Puppet detect these and install drivers apropriatelly
[00:18] <ivo_cavalcante> but I'd like your input on this
[00:18] <ivo_cavalcante> maybe I'm not following a good path...
[00:18] <rbasak> Maybe the server installer automation and requesting ubuntu-desktop^ as a package will give you a desktop approximation
[00:18] <rbasak> But like I say I don't know what issues might result from that.
[00:19] <ivo_cavalcante> let'me try a different question:
[00:19] <rbasak> Any path you follow here is unsupported. I think you need to be prepared to find issues and plan to deal with them when they arise whichever way you go.
[00:19] <ivo_cavalcante> autoinstaller support custom input questions?
[00:19] <rbasak> I don't think it does.
[00:19] <rbasak> You can arrange for existing questions to automatically use the default, or prompt, IIRC.
[00:20] <ivo_cavalcante> hum
[00:20] <ivo_cavalcante> I was almost sure that'd be the case
[00:20] <rbasak> You could patch the installer I suppose.
[00:21] <ivo_cavalcante> we don't have enough manpower to support this
[00:21] <ivo_cavalcante> I know there are hacks I could do, but want to have it as pristine as possible
[00:21] <ivo_cavalcante> but you were very helpful, thanks
[00:22] <rbasak> What you're asking for doesn't (AFAIK) exist. So getting what you want requires manpower already.
[00:22] <rbasak> np
[00:22] <rbasak> Sorry I can't give you an easy answer!
[00:22] <ivo_cavalcante> yes, was hoping it did exist
[00:22] <ivo_cavalcante> :)
[00:22] <rbasak> I could be wrong FWIW.
[00:22] <ivo_cavalcante> np, not a typical scenario
[00:22] <rbasak> I'm answering to the best of my knowledge.
[00:22] <ivo_cavalcante> np
[00:24] <ivo_cavalcante> oerheks: the mini ISO has some kind of install interface?
[00:24] <ivo_cavalcante> or is just a plain ISO ?
[00:29] <oerheks> minimal iso is atext based installer, not suitable for UEFI sofar i know..
[00:29] <oerheks> also, this post might be a help with preseeding / cubic https://www.pugetsystems.com/labs/hpc/Note-Auto-Install-Ubuntu-with-Custom-Preseed-ISO-1654/
[09:05] <sigv> I have an internal domain that I use -- example.com -- configured from /etc/hostname.
[09:05] <sigv> When using Azure, DHCP gives you an additional DNS suffix. To quote MS Docs: "When you are using your own name resolution solution, this [DNS] suffix is not supplied to VMs because it interferes with other DNS architectures (like domain-joined scenarios). Instead, Azure provides a non-functioning placeholder (reddog.microsoft.com)."
[09:06] <sigv> All is well generally, but systemd-resolved seems to pick up both domain names as usable suffixes.
[09:06] <sigv> So if you look up `abc` then that expands to both `abc.example.com.` and `abc.reddog.microsoft.com.` after that. I would like to tell systemd-resolved to ignore the DHCP suffix.
[09:07] <sigv> Any pointers how I would configure that to the best practices? Can't seem to wrap my head around Domains= in the configuration there, and that might not even be the right direction.
[10:19] <RoyK> sigv: it's generally a good idea not to use existing domains as your own test domains ;)
[10:19] <RoyK> sigv: better use myfinedomain.local or something similar. .local is meant for that
[11:25] <sigv> RoyK: oh it's not that - we do have a real domain in a real TLD, I just used example.com as an example there. Sorry for not clarifying that.
[11:25] <sigv> The question still stands of how to remove the DHCP DNS suffix/domain from systemd-resolved.
[11:28] <sigv> RoyK: To expand on the domain name usage: The servers register their IP addresses linked with hostnames in the internal Active Directory DNS, and our split DNS structure is set up fine where internal infrastructure gets all the results and public DNS servers provide a minimal set of domains (split DNS setup basically).
[11:29] <sigv> RoyK: The concern is still appreciated and it's true that nobody should be using domain names they do not own! I did a migration from the previous sysadmin/operator away from such a domain actually, and that was a fun experience together with Windows machines, but that's a different story entirely. :)
[16:12] <sigv> netplan's DHCP overrides' use-domains looks promising, will try poking into that direction.
[20:21] <shubjero> coreycb: Will OpenStack Victoria be built for 18.04?
[20:21] <shubjero> Or is Ussuri the end of the road for 18.04?
[20:27] <coreycb> shubjero: ussuri is the last release of openstack backported to 18.04
[20:28] <shubjero> coreycb: ok, looks like I have a big project for 2021 ahead of me!
[20:28] <coreycb> shubjero: heh