[05:31] <damascene> hello, as asked in #KVM I want to allow a virtual instance to use network in bridge mode. I'm on Ubuntu 18.04 which uses netplan. That confused me a lot if any one knows how to do it please advice. I read multiple articles but the setup didn't work for me. each one of the should have static IP
[05:37] <damascene> headless server
[05:57] <lotuspsychje> !netplan | damascene start here
[05:57] <lotuspsychje> damascene: im not the server expert myself, but netplan uses the yaml file to edit your routes in
[05:58] <lotuspsychje> ask again here Rembo
[05:58] <Rembo> hello, does one of the following patches require reboot? https://pastebin.com/GvPpQFi3
[05:58] <Rembo> does grub patches require reboot after patching on Ubuntu 16.04 Server ?
[06:11] <damascene> lotuspsychje, thank you for trying to help, I've tried many solution and edited the yaml file. I'm being locked out of PC
[06:16] <lotuspsychje> as again here whitebyte
[06:17] <lotuspsychje> also you might need to patient a bit, -server support wakes up more at US wakeup
[06:17] <whitebyte> I have setup Kea DHCP on ubuntu-18.04 server and trying to set hostname for a client ubuntu 18.04 machine. The hostname is passed in the lease file provided by kea-dhcp server but that is not taking any effect on client machine.
[06:17] <whitebyte> sure @lotuspsychje
[06:22] <lordievader> Good morning
[06:23] <gnomethrower> oh nice
[06:23] <gnomethrower> i had no idea this was a channel
[06:24] <gnomethrower> should the link in the topic be referencing 18.04? :)
[06:24] <gnomethrower> (ping Pici )
[07:10] <damascene> I wanted to setup network interface not to write python code what the hell with this yaml
[07:11] <damascene> I'm unable to know if the issue is with indenting or wrong configuration it keeps complaining as if is saying anything smart
[07:15] <damascene> how to modify this to add KVM bridge? https://paste.ubuntu.com/p/sQWcpKQdyN/
[07:15] <damascene> ip for the bridge should be 192.168.1.121
[08:45] <damascene> could you please me add a bridge to my netplan file? https://paste.ubuntu.com/p/yw8gpBgMN2/
[08:45] <damascene> I've tried many configuration but I'm getting thrown out of the server
[09:39] <lotuspsychje> re-ask here chl_ ; )
[09:40] <chl_> i've set option 66 and option 67 in isc-dhcp, but its not appearing on the dhcp packets if I check by dhcpdump. Has anyone had that problem?
[13:51] <leftyfb> So I reported bug #1820096 and it got fixed. The problem is, I cannot seem to recreate the issue and in fact, have found that adding the hosts entry back in breaks tools like dnsdomainname. So now I'm debating whether or not the fix should be reverted.
[13:54] <patstoms> morning, is there any other service which do scheduling other than irqbalance?
[14:21] <ahasenack> rbasak: hi, quick look? https://code.launchpad.net/~ahasenack/usd-importer/+git/usd-importer/+merge/367112
[14:24] <leftyfb> ahasenack: any suggestions on what we should do about #1820096 and the 127.0.1.1 entry in /etc/host for Ubuntu server? Is this something you can test on your end as well?
[14:25] <ahasenack> in principle I would remove it on a server
[14:26] <leftyfb> That's what I'm thinking. But in my initial testing with 18.04 server using the subiquity installer, with the entry there, the system wasn't registering it's hostname with dhcp/dns. Now I can't seem to reproduce the issue.
[14:27] <rbasak> I'm not sure I follow your exact problem.
[14:27] <rbasak> The generally right thing that's needed is
[14:27] <rbasak> 127.0.0.1 localhost
[14:27] <rbasak> 127.0.1.1 hostname-without-dots fqdn
[14:27] <rbasak> in /etc/hosts
[14:28] <rbasak> and hostname-without-dots in /etc/hostname
[14:28] <rbasak> And the system hostname set without dots (which happens from /etc/hostname on boot, or use the hostname command)
[14:28] <rbasak> I believe that's the current Debian and Ubuntu standard.
[14:28] <rbasak> The RH world is different I think.
[14:29] <rbasak> fqdn in /etc/hosts can be missing if you don't have one
[14:29] <leftyfb> well no, not with server. From what I understand, the 127.0.1.1 is only to work around a bug in some gnome applications that don't work unless we can do a local lookup of our hostname with no network or on a network without a local DNS server that will resolve it. Otherwise (server) it shouldn't be needed
[14:29] <rbasak> dnsdomainname et al should then just work.
[14:30] <leftyfb> rbasak: with the default 127.0.1.1 entry(no fqdn), dnsdomainname does not work
[14:30] <rbasak> You can get away without 127.0.1.1 like in your example, but it requires an extra round trip to your DNS server so why have it set up that way? The one way that is (should be?) installer default works in all cases, including dynamic, no FQDN, etc.
[14:31] <rbasak> leftyfb: with no fqdn, dnsdomainname returns empty, as expected.
[14:32] <rbasak> Any machine should be able to look up its own name, and know its own FQDN, without resorting to the network.
[14:32] <leftyfb> rbasak: but on the network, the system does have a fqdn, so it should return it's valid hostname. Just because the 127.0.1.1 entry fails at adding the fqdn, does not mean the system does not have one on the network
[14:32] <ahasenack> rbasak: I don't recall how this works, should I merge https://code.launchpad.net/~ahasenack/usd-importer/+git/usd-importer/+merge/367112, wait for the bot to run tests, both, something else?
[14:32] <rbasak> ahasenack: wait for the bot and if it passes go ahead and merge please
[14:32] <ahasenack> ok
[14:33] <rbasak> leftyfb: I don't follow your statement
[14:33] <rbasak> leftyfb: what's the problem you're trying to solve? Do you have a failing or illustratively-bad use case?
[14:34] <leftyfb> rbasak: if there's a 127.0.1.1 entry, without a fqdn, and the lookup says there is not fqdn, that is returning false information. There is a fqdn, but we're being forced to use the file as opposed to dns and not able to look it up properly
[14:34] <rbasak> leftyfb: how is it that you ended up with a 127.0.1.1 entry without an fqdn? And what do you mean by "forced to use"?
[14:34] <leftyfb> rbasak: On my network, my devices have fqdn's on the network per the local DNS server. I want to use dnsdomainname to lookup what the domain is. That fails when there is a 127.0.1.1 entry without a fqdn.
[14:35] <rbasak> leftyfb: why haven't you told your machine its fqdn during installation?
[14:35] <leftyfb> rbasak: forced per the nsswitch order. If "file" has an entry, we don't don't bother looking up "dns"
[14:36] <leftyfb> rbasak: To start with, the fqdn can and will change depending on which network(domain) the machine connects to. Hardcoding it is not the right solution.
[14:36] <leftyfb> rbasak: And there's no way to populate /etc/hosts with a fqdn with dhcp
[14:36] <rbasak> leftyfb: why do you need the machine's idea of its "fqdn" to change as it moves around?
[14:37] <leftyfb> rbasak: because it's on a different domain and we want to determine which domain we are on by using the tool meant to do so (dnsdomainname)
[14:37] <rbasak> You're going to have to go through the five whys here, sorry.
[14:38] <leftyfb> rbasak: what do you mean?
[14:38] <rbasak> I don't see how it's a problem for the machine to consider itself to have a blank fqdn.
[14:38] <leftyfb> rbasak: because it's not valid
[14:38] <rbasak> As a road warrior laptop user, I don't want other networks to inject bad data into my laptop.
[14:39] <rbasak> It's perfectly valid, and until someone persuades me otherwise, it's even preferable
[14:39] <leftyfb> rbasak: In our particular case, we have robots that move between networks (customer sites) with different domains and we want to use dnsdomainname to determine which domain we are on in order to set some variables
[14:40] <rbasak> It sounds like it might not be the right thing to be using dnsdomainname in that case.
[14:40] <leftyfb> rbasak: If a device on a network has a valid fqdn that every other machine on the network knows about, then it is not valid for dnsdomainnam to lie and say there isn't one.
[14:40] <rbasak> What happens if you have two NICs that both DHCP and get conflicting "FQDN"s?
[14:41] <rbasak> Perhaps better for your software to do a reverse lookup on the IP of one network interface it's interested in.
[14:41] <rbasak> That would more unambigiously identify "what network you're on".
[14:42] <leftyfb> rbasak: so you're ok with broken tools? For what purpose? Because you want to keep an entry that was only put there to work around a bug in some Gnome applications which aren't relevant in a server install?
[14:42] <rbasak> Who said it's broken?
[14:42] <rbasak> I think you're making a false assumption here about what the tool is supposed to do for you.
[14:43] <compdoc> biggest problem with 2 nics and dhcp, is getting two gateways set for the pc
[14:43] <leftyfb> "dnsdomainname - show the system's DNS domain name"
[14:43] <rbasak> See the manpage example that uses 127.0.1.1!
[14:43] <rbasak> Via /etc/hosts
[14:45] <leftyfb> The only way to populate /etc/hosts is manually. That is a bad way to use the tool to "show the system's DNS domain name" which has a valid fqdn on the network
[14:45] <cryptodan> you could simply add it to the hostname config at install when you give the computer a hostname
[14:46] <leftyfb> We're not talking about at install. The FQDN is going to change across multiple networks/domains.
[14:48] <leftyfb> The only reason the entry exits in the first place is from https://www.linuxtopia.org/online_books/linux_system_administration/debian_linux_guides/debian_linux_reference_guide/ch-gateway.en_009.html
[14:48] <leftyfb> which is for a desktop environment, not server
[14:48] <rbasak> I'm saying that for the FQDN to dynamically change as you roam between networks is broken in the general case.
[14:48] <rbasak> I don't think a default Ubuntu installation should be doing that by default.
[14:49] <leftyfb> rbasak: why do you say that is broken?
[14:50] <rbasak> Just because I'm connecting to some random wifi somewhere doesn't mean that my FQDN should change.
[14:50] <rbasak> And on a server, an FQDN change should certainly only happen directly when a sysadmin wants it, and not automatically.
[14:50] <rbasak> (by default)
[14:50] <leftyfb> It 100% means it should change if you are on a network with a different domain.
[14:50] <rbasak> I don't think that meets normal sysadmin expectations.
[14:51] <rbasak> Networks don't have "domains".
[14:52] <leftyfb> I don't even know how to respond to that
[14:53] <rbasak> An individual IP address issued by a DHCP server may reverse lookup to something whose FQDN has something specific according to the DNS server provided by the DHCP lease issued by the DHCP server to that IP address.
[14:53] <rbasak> That's something that's per-IP though, not per-network.
[14:59] <leftyfb> rbasak: ok, so to be clear, you're saying the current state should be:  We want a bug workaround for Gnome applications to stay in Ubuntu server for ${reasons}, we don't want dnsdomainname to actually be able "show the system's DNS domain name" from DNS and "Networks don't have "domains".
[15:02] <rbasak> leftyfb: no.
[15:02] <rbasak> leftyfb: I make no reference to any workaround.
[15:03] <rbasak> leftyfb: my reasons for supporting the long standing standard for how this work stand on their own merits.
[15:03] <leftyfb> rbasak: and yet, before my bug report, the entry was removed from the subiquity installer
[15:03] <leftyfb> So someone made the decision at some point in the past year to remove it
[15:04] <rbasak> leftyfb: are you saying that the current state of the installers don't match my position?
[15:05] <leftyfb> rbasak: The current state of the latest available Ubuntu live server installer iso does not match your position
[15:05] <rbasak> leftyfb: what does it do instead?
[15:05] <leftyfb> rbasak: it does not have an entry for 127.0.1.1
[15:05] <cryptodan> but why should it
[15:06] <rbasak> leftyfb: in what scenario? Manual IP entry?
[15:06] <rbasak> leftyfb: what exactly does it do?
[15:07] <leftyfb> rbasak: As basic of an install as you can do, with dhcp and only setting a hostname during the install
[15:08] <rbasak> leftyfb: does it add a 127.0.0.1 entry? If so with what? Just localhost?
[15:08] <leftyfb> yes and yes. But let me do a quick install to doublecheck
[15:22] <leftyfb> Taking longer than expected. We moved the lab around yesterday and don't have a wired connection to my test devices at the moment. The live installer takes forever timing out trying to get to the repos and falling back to the usb
[15:23] <rbasak> leftyfb: no worries. Feel free to ping me when you're ready. I appreciate the discussion, and would like there to be a consistent position and bugs open against installers as needed referring to that position.
[15:25] <rbasak> leftyfb: seems that my position may need to change to accomodate the DHCP during install + no FQDN supplied during install case.
[15:35] <leftyfb> rbasak: https://photos.app.goo.gl/FLDqgAy5VPfrfz4B9
[15:36] <leftyfb> Using ubuntu-18.04.2-live-server-amd64.iso
[15:37] <rbasak> leftyfb: is that with the fix to bug 1820096? Or does it describe bug 1820096 and it's pending release?
[15:38] <leftyfb> Yes. Though the odd part is I can't seem to reproduce the issue now.
[15:38] <leftyfb> I'm wondering if mwhudson was able to
[15:38] <leftyfb> and if he still can
[15:39] <leftyfb> and if the bug should be invalidated or the fix kept
[15:39] <leftyfb> oh wait
[15:39] <leftyfb> rbasak: no, that is NOT with the fix
[15:39] <rbasak> OK
[15:39] <leftyfb> rbasak: In order to get the fix, I would need to snap refresh and get the latest subiquity installer.
[15:39] <rbasak> So my position is slightly different (but fundamentally remains the same IMHO)
[15:40] <rbasak> In the case that DHCP is all that is used, and an FQDN is never provided at install time, then it makes sense to have a 127.0.1.1 line with the non-qualified hostname only.
[15:40] <rbasak> (by default; the sysadmin can change later of course)
[15:40] <leftyfb> I'd like to find the bug and/or discussion that was had to decide on removing the entry for the live installer. That would give us more insight into whether it's actually needed
[15:41] <rbasak> Rationale: any FQDN provided indirectly via DHCP and DNS at install time cannot be trusted to be the correct FQDN for the final installation.
[15:42] <leftyfb> rbasak: why do you say it cannot be trusted? I don't understand that reasoning. You're making decisions based on the assumption that the server install is running on untrusted networks providing "invalid" fqdn's to clients on the network.
[15:43] <rbasak> leftyfb: it's quite common for non-automated installs to be done in some kind of non-production network with different settings.
[15:44] <leftyfb> rbasak: ok. But why hardcode such that we do not have a FQDN and have no way of using the tool meant to look it up?
[15:44] <rbasak> Hardcode how?
[15:46] <leftyfb> rbasak: If you write an entry for 127.0.1.1 without the fqdn, you are hardcoding invalidating any fqdn lookups
[15:46] <Ussat> rbasak, even some automated install will do install in a non-prod network if you are building replacement servers....build, change vlan/hostname/ip replace
[15:46] <Ussat> we do that all the time
[15:47] <leftyfb> rbasak: But again, I refer to the Debian documentation stating that the entry was only there in the first place to allow some gnome applications to not break when trying to do a fqdn lookup when we have no network or local DNS server which will resolve the client's fqdn. This does not apply to server installs. Especially ones running on a network with a local dynamic DNS server
[15:47] <rbasak> leftyfb: OK. I call that "the system doesn't have a defined FQDN", which is IMHO correct.
[15:47] <leftyfb> rbasak: the entry does not exist in any other linux distro other than Debian-based
[15:48] <rbasak> Ussat: agreed
[15:48] <rbasak> leftyfb: I think the current behaviour is sensible behaviour, barring that current subquity bug.
[15:48] <leftyfb> rbasak: you cannot make that assumption if you don't look it up on the network
[15:49] <rbasak> leftyfb: you're already on very strange territory to have a non-cloud server installation running DHCP that didn't know its own hostname and FQDN at installation time.
[15:49] <rbasak> leftyfb: that the default doesn't work for you isn't surprising to me.
[15:49] <rbasak> leftyfb: you can override default behaviour by changing /etc/hosts :-)
[15:50] <leftyfb> rbasak: I disagree. And we do know our hostname. But for devices that join multiple networks with different domains, no, we do not yet know our FQDN until we are on the network that provides it.
[15:50] <leftyfb> A FQDN should not be defined by the client but the network it's on
[15:50] <rbasak> Sure. I mean you don't know your own (hostname and FQDN) :)
[15:51] <rbasak> As I said before, that doesn't work for multi-homed hosts.
[15:51] <rbasak> You can't make a general statement about what should define an FQDN.
[15:51] <rbasak> It's up to the sysadmin in an individual environment who knows the type of network environment it'll be operating in.
[15:51] <leftyfb> It does when you're not doing something stupid like looking up your FQDN across different DNS servers hosting different domains
[15:53] <leftyfb> Just because your client likes to pretend it's FQDN is host.google.com in /etc/hosts, does not mean any other machine on the network is going to agree. The client does not decide what it's FQDN is
[16:08] <rbasak> leftyfb: there's a difference between what a client considers its FQDN to be and what points to it via an A or AAAA record, and what reverse lookups via in-addr.arpa and in6.arpa say. They can all disagree.
[16:09] <rbasak> leftyfb: therefore it's up to the sysadmin to decide which one is the canonical FQDN. You cannot infer it.
[16:09] <rbasak> leftyfb: and therefore it is not a function of the network.
[16:10] <rbasak> Though it is generally a misconfiguration somewhere if a machine's FQDN exists in DNS but points to some other machine.
[16:17] <whitebyte> I have setup Kea DHCP on ubuntu-18.04 server and trying to set hostname for a client ubuntu 18.04 machine. The hostname is passed in the lease file provided by kea-dhcp server but that is not taking any effect on client machine.
[17:10] <teward> !crosspost | whitebyte
[17:15] <whitebyte> @ubottu Sorry. I will keep in mind
[17:17] <ahasenack> whitebyte: check if you have the hostname in /etc/hosts
[17:17] <ahasenack> maybe that's overriding it
[17:19] <ahasenack> paride: around still?
[17:20] <ahasenack> rbasak: any idea why ci hasn't run on my git-ubuntu branch yet?
[17:21] <ahasenack> I'm not seeing errors in https://jenkins.ubuntu.com/server/view/git-ubuntu/job/git-ubuntu-ci/
[17:22] <whitebyte> @ahasenack I have only `127.0.0.1 localhost` in /etc/hosts
[17:24] <ahasenack> ok
[17:29] <ahasenack> rbasak: I wonder if it's about an MP limit, I count 10 skips in the job logs
[17:29] <ahasenack> https://jenkins.ubuntu.com/server/view/git-ubuntu/job/git-ubuntu-ci-trigger/57736/console
[17:31]  * ahasenack wonders where launchpadTrigger comes from
[17:59] <whitebyte> I am getting `Not connected to system bus, not setting hostname` in syslog from systemd-network.service. Can I force networkd to start after dbus.service is up
[17:59] <leftyfb> rbasak: A FQDN is a function of the network regardless of what the client thinks it is. The rest of the network doesn't give one lick what the client thinks it is and will only resolve what the network(DNS server) thinks it is. Playing pretend in /etc/host is a workaround for lack of network connectivity or a DNS server which will resolve the hosts FQDN.
[19:07] <rbasak> ahasenack: limit> yeah maybe. paride looks after the job, so he might know? You can manually trigger a job using https://jenkins.ubuntu.com/server/view/git-ubuntu/job/git-ubuntu-ci/build?delay=0sec
[19:08] <ahasenack> rbasak: we found out, the mp was approved already, so ci didn't look at it
[19:08] <rbasak> Ah
[19:08] <ahasenack> rbasak: I merged it
[19:08] <ahasenack> (after ci's approval)
[19:08] <rbasak> \o/
[19:16] <gislaved> guys does a tftp client check UDP and TCP both ?
[19:17] <RoyK> tftp is udp only
[19:23] <gislaved> RoyK you can configure it on TCP
[19:25] <sarnold> I've never seen tftp on tcp
[19:28] <gislaved> you can otherwise you cannot loadbalanc eit
[19:28] <gislaved> *loadbalance
[19:29] <gislaved> or less easy
[19:32] <sarnold> it's tftp. I can't imagine that it is ever under that kind of load.
[19:32] <gislaved> sarnold have you ever seen a tftp server crashing ?
[19:32] <sarnold> no, they don't do anything complicated :)
[19:32] <gislaved> sarnold I need failover, LB-er is most easy for that
[19:32] <gislaved> then I can just cehck if the server is alive :)
[19:32] <gislaved> heh maybe it's time for anycast
[19:35] <sdeziel> gislaved: if you really need to LB multiple TFTP servers with healthchecks and what not, you can use keepalived/ipvs I think
[19:35] <gislaved> sdeziel I think I can let HAproxy do that, it does not support UDP but I think it can just let it foreward
[19:36] <sdeziel> gislaved: I don't know if HAproxy can handle UDP at all
[19:37] <sdeziel> gislaved: for DNS, I've also used IPtables with random module to spread the load among multiple servers ... quick and dirty but it works
[19:37] <gislaved> sdeziel normally not but I have doen DNS loadbalancing as well in the past, so let's see
[19:37] <gislaved> sdeziel not that dirty :)
[19:38] <sdeziel> you can get creative with how you do it with iptables so that you remove backends when they are down but there is no builtin healthcheck which is why I said it was dirty ;)
[19:40] <gislaved> heh :)
[19:44] <sdeziel> gislaved: that said, even under load, I wouldn't expect the service to crash, which package is it?
[19:44] <gislaved> sdeziel me neither. xinetd
[19:44] <rbasak> leftyfb: again, that's not generally true. Say for example I have a web server on AWS. In that case, the network the instance sees has nothing to do with the real FQDN of the server.
[19:45] <sdeziel> gislaved: have you tried tftpd-hpa?
[19:45] <gislaved> sdeziel not yet, not supported by foreman
[19:45] <leftyfb> rbasak: and equally irrelevant is a fqdn entry in /etc/hosts on that instance
[19:46] <rbasak> leftyfb: I'd want all services on that instance to see the "right" fqdn, so I would set it correctly in /etc/hosts. I don't see how that's irrelevant.
[19:47] <leftyfb> rbasak: I would point the instance to a proper DNS server that knows about the fqdn to do the lookup. Hardcoding entries in /etc/hosts is a hack
[19:48] <rbasak> leftyfb: that won't work, because the instance won't have its public IP address actually assigned to an interface
[19:48] <rbasak> leftyfb: I don't think the server's _own_ entry in /etc/hosts against 127.0.1.1 is a hack.
[19:48] <rbasak> In the general case for other hosts, yes.
[19:48] <sdeziel> gislaved: I'd try that one first personally. It's the only tftpd I can see in 'main' and I've seen many deployments using it (although I don't know how many tftp clients you hit your server with...)
[19:48] <rbasak> But for a machine to know its own name and fqdn, that's not a hack. It's the status quo.
[19:48] <gislaved> sdeziel not that much but I hate to have things "down"
[19:49] <rbasak> DNS isn't necessary for a host to have a name.
[19:49] <leftyfb> No, you're right. It's a big fix for some desktop applications
[19:49] <rbasak> (and fqdn)
[19:49] <leftyfb> It is for anything else on the network to utilize the fqdn
[19:49] <sdeziel> gislaved: I personally wouldn't trust xinetd for production stuff
[19:50] <gislaved> sdeziel why not ? it's the most known one that alw ays work(s)(ed)
[19:50] <gislaved> *always
[19:52] <sdeziel> gislaved: I've only ever used dnsmasq and tftpd-hpa myself and the fact that the later is in main (while xinetd is in universe) speaks for itself
[19:52] <gislaved> sdeziel it's supported by RH so I trust it :)
[19:56] <rbasak> leftyfb: it's useful for various things. Like HTTP error pages being correct, etc.
[20:17] <Aison0> hello, anybody experienced with freeradius and openssl 1.1.1b? since 1.1.1b freeradius logs these kind of messages: https://pastebin.com/SacLArvy
[20:18] <Aison0> I upgraded my notebook to disco and now freeradius logs these kinds of errors on the ubuntu server
[20:26] <sarnold> Aison0: might be worth a filing a bug with ubuntu-bug
[20:27] <Aison0> sarnold, the problem is, I don't know if it is really related to that upgrade :-)
[20:27] <Aison0> or is this a openssl-1.1.1b thing
[20:30] <sarnold> it feels plausible anyway
[22:49] <Disaster_Area> Hi! I'm used to using MS SQL Server at work and basically want to use something similar at home for fun. I managed to install SQL server at home on Ubuntu 16.04 but
[22:49] <Disaster_Area> well a) recommended GUIs/CLIs
[22:49] <Disaster_Area> b) why do I get some syntactical errors I don't get when using MS SQL Server, e.g. https://i.imgur.com/boLOU6C.png
[22:51] <sarnold> hey Disaster_Area, you may have more luck in an ms-sql channel; someone here might be able to help with postgresql or mariadb or sqlite3, but mssql is pretty rare
[22:52] <Disaster_Area> hmm I was pointed this way from #ubuntu ok I'll have a look over there
[22:54] <sarnold> yeah, I can see how they would have aimed you this way :) but I *think* you're the first person I've seen use mssql :)
[22:55] <OerHeks> oh, ms sql
[22:55] <michael2> I have wanted to tinker with it, but haven't yet
[22:55] <OerHeks> is this on WSL?
[22:55] <Disaster_Area> yeah I picked up SQL at work first ever programming language or anything for me haha well touched python and R a little bit
[22:55] <Disaster_Area> WSL?
[22:56] <michael2> Windows Subsystem for Linux
[22:56] <sarnold> OerHeks: MS releases MSSql *for* linux
[22:56] <sarnold> no need to run mssql on wsl, you could just run it on windows windows :)
[22:56] <Disaster_Area> so I'm on linux at home and I wanted to use something like I'm used to at work rather than having to pick up a different variant
[22:56] <michael2> are you having trouble installing it?
[22:56] <Disaster_Area> I've installed MS SQL server on linux fine but
[22:57] <Disaster_Area> I was asking for advice on GUIs/CLIs and
[22:57] <OerHeks> hardening?
[22:57] <michael2> I have used dbeaver community edition
[22:57] <Disaster_Area> I ran some code that creates a simple function with some while loops in that works on MS SQL Server Studio but didn't run at home
[22:58] <sarnold> Disaster_Area: maybe try a much simpler function? something that just returns an integer?
[22:59] <Disaster_Area> I'll have a stab at that sure
[23:00] <Disaster_Area> that worked ok
[23:01] <Disaster_Area> hmm what should I post my SQL output in, might be quicker than sharing a screenshot
[23:02] <Disaster_Area> or is pastebin fine? \shrug/
[23:02] <sarnold> the pastebinit tool makes pasting easy -- you can pastebinit /path/to/file  and then just copy-paste the URL you get back
[23:02] <Disaster_Area> https://pastebin.com/h1EXGNeD
[23:02] <sarnold> nice
[23:03] <sarnold> now try a tiny loop.. one variable, small body..
[23:04] <Disaster_Area> haha I keep fucking it up every time I try and code it, and this is why I need a better interface
[23:04] <Disaster_Area> bc with this u cant go back and edit the same thing u can just scroll up to find lines you already wrote ....
[23:05] <sarnold> ew :)
[23:05] <sarnold> can you use a text editor like vim or emacs or whatever and feed that as input?
[23:05] <michael2> Disaster_Area: Give dbeaver a try
[23:05] <Disaster_Area> https://pastebin.com/RHA26uSL
[23:06] <Disaster_Area> i've got no idea haven't tried & don't have experience with that stuff
[23:06] <Disaster_Area> the MS doc mentioned azure data studio and a couple other interface options
[23:06] <michael2> dbeaver is a lot like Sql Server Management Studio
[23:07] <Disaster_Area> hmm
[23:07] <Disaster_Area> i'll look it up
[23:07] <michael2> the Community Version is free and works with sql server and many others
[23:08] <Disaster_Area> looks neat thanks I'll try it I think
[23:08] <michael2> I like it because I can use the same interface for ms sql, mysql, postgres, maria...
[23:09] <Disaster_Area> ooh hm I need to install java or something hmmmmm
[23:10] <Disaster_Area> I fucked up my java situation really bad so like
[23:10] <Disaster_Area> I had downloaded openjdk when I moved to the OS so I could run minecraft
[23:10] <Disaster_Area> then when I was applying for jobs outta uni one of them was for a java thing and the guy on the phone basically pushed me into trying to learn it
[23:10] <Disaster_Area> which on linux meant a lot of effing around with uninstalling and installing stuff
[23:16] <Disaster_Area> oops appears i disconneted >_>
[23:16] <Disaster_Area> haha here we go installed it and tried to run and got the following error message:
[23:16] <Disaster_Area> A Java Runtime Environment (JRE) or Java Development Kit (JDK)
[23:16] <Disaster_Area> must be available in order to run Dbeaver. No Java virtual machine
[23:16] <Disaster_Area> was found after searching the following locations:
[23:16] <Disaster_Area> java in your current PATH
[23:17] <Disaster_Area> --usr/share/dbeaver/jre/bin/java that was the location it gave
[23:17] <Disaster_Area> buuut when I tried updating my java earlier:
[23:18] <Disaster_Area> https://pastebin.com/EqX5NgeT
[23:18] <Disaster_Area> would there be a better place for me to ask how to sort this issue out? lol
[23:20] <OerHeks>  9 not to upgrade. run apt full-upgrade
[23:21] <Disaster_Area> i'll try that see if it helps
[23:23] <Disaster_Area> still same error msg
[23:26] <Disaster_Area> hmm its weird it gives the usr/share/... since there is no jre folder in usr/share/dbeaver ...
[23:27] <tomreyn> maybe dbeaver have a support channel? it's not part of ubuntu's software repositories, so unless michael2, who is apparently familiar with it, can help you out, you'll better look for a software specific community support channel
[23:29] <Disaster_Area> hmm good idea
[23:29] <Disaster_Area> though this might be more of a java issue honestly
[23:30] <tomreyn> as long as you have apt package "default-jre" installed, this should be all that's needed if the software you're using was made to be ubuntu compatible.
[23:30] <Disaster_Area> think I was missing that..........
[23:30] <Disaster_Area> thanks!!
[23:32] <tomreyn> it's really just a tracking package for the latest openjdk*-jre package, which you seemed to have already
[23:32] <tomreyn> ahem, "default-jre-headless" is what you'd want on a headless server, sorry.
[23:34] <Disaster_Area> it installed that one too
[23:34] <Disaster_Area> aaaand dbeaver still same complaint
[23:35] <Disaster_Area> on the other hand how do I find my java path?
[23:35] <Disaster_Area> i think i can do it if I can find that?
[23:38] <tomreyn> "apt depends <package_a>" lists the other packages package_a depends on.
[23:39] <tomreyn> "dpkg -L <package>" lists the files (and paths) which belong to the given package
[23:41] <tomreyn> you just reached the point where a moderate understanding of ubuntu's software management utilities could be useful.
[23:41] <Disaster_Area> hm i found the path
[23:41] <Disaster_Area> yeah I really could do with knowing the ins and outs of knowing my OS better at this point in time
[23:42] <tomreyn> chances are you'd be better off with these (also normally unsupported here, just like the ones you have now, and mssql) dbeaver packages: https://launchpad.net/~serge-rider/+archive/ubuntu/dbeaver-ce?field.series_filter=xenial
[23:43] <Disaster_Area> i dont think its a case of missing packages i think it just needs me to tell it where java is
[23:44] <tomreyn> on linux it's common to build and package software multiple times for different distributions, to make the software apply to the different environments.
[23:44] <tomreyn> e.g. one distro may have java binaries in one path, the other in another path.
[23:46] <tomreyn> also by using apt repositories you get an easy and secure upgrade path
[23:47] <Disaster_Area> well, I did install the default-jre and default-jre-headless and it didnt appear to have helped... anyway so i tried some things and
[23:49] <Disaster_Area> https://pastebin.com/zVDiVs1q
[23:51] <Disaster_Area> oh hmm this is good
[23:51] <Disaster_Area> the filepath i found at the top
[23:51] <Disaster_Area> doesn't exist any more
[23:51] <Disaster_Area> >_>