| * runelind_q upgrades LDS | 00:31 | |
| runelind_q | let's see if it blows up. | 00:32 |
|---|---|---|
| === minipini is now known as Guest67672 | ||
| cpaelzer | good morning | 05:22 |
| lordievader | Good morning | 05:56 |
| * Eichu0Ku_ | 07:25 | |
| V7 | Hey all | 09:18 |
| V7 | How to chroot a user correctly, so it won't move upper path ? | 09:19 |
| V7 | Can't login after adding ChrootDirectory to sshd_config for a user | 09:19 |
| V7 | Now it looks like: https://hastebin.com/xutizafebu.nginx | 09:19 |
| V7 | Ubuntu 18.04 | 09:19 |
| blackflow | V7: can you login with sftp? | 09:27 |
| blackflow | V7: also, there are certain rules about chrooted directories. check the ssh logs. Namely, the chroot directory must be owned by root. So it can be something like root:user ownership, and 750 mode, ie. not accessible by others. | 09:28 |
| ducasse | V7: please don't crosspost, it's pretty rude and wastes other people's time | 09:29 |
| V7 | ducasse: No answer there in about 15 mins so | 09:30 |
| V7 | Thank you blackflow. sftp gives: Couldn't read packet: Connection reset by peer | 09:31 |
| ducasse | V7: you posted in #linux 3-4 minutes before here | 09:31 |
| blackflow | V7: and what do the server logs say? | 09:31 |
| V7 | ducasse: Please, sorry. | 09:32 |
| V7 | blackflow: YOu're right. Says bad onwership or modes for chroot | 09:33 |
| blackflow | mmmh-hm. | 09:33 |
| blackflow | V7: and btw, that will only allow SFTP access. You can't ssh into that account regularly. | 09:33 |
| V7 | You mean, force-command ? | 09:34 |
| blackflow | if you want to ssh regularly, you'll have to populate the chroot dir with some nodes required for interactive session. see the sshd_config manage on ChrootDirectory directive. | 09:34 |
| blackflow | V7: yes, force-command. | 09:34 |
| V7 | This is an achievement :) | 09:34 |
| blackflow | but not just it. like I just said, if you want regular ssh access too, you need some nodes in the chroot dir. | 09:34 |
| V7 | This user mustn't use ssh | 09:35 |
| V7 | shell * | 09:35 |
| blackflow | V7: it's all explained nicely under the ChrootDirectory option in the sshd_config(5) manpage. | 09:35 |
| blackflow | V7: in that case, this config should suffice, assuming you have proper ownership like explained earlier. | 09:35 |
| V7 | I'm actually, already reading | 09:35 |
| V7 | Thank you very much blackflow | 09:36 |
| blackflow | you're welcome. | 09:36 |
| === mike-zal is now known as mike-zal-work | ||
| jamespage | coreycb: I'm thinking we should move to <agent binpkg> -> python{3}-<module> -> <module>-common as a general pattern | 09:52 |
| jamespage | so all the agent binpkgs do is provide the systemd units | 09:52 |
| jamespage | osa will like that as well | 09:52 |
| V7 | blackflow: Oh dear. | 11:02 |
| V7 | Now an ownership is okay, isn't it ? https://hastebin.com/ukutogevet.coffeescript | 11:07 |
| V7 | Although, it shows an error while trying to authorize with user | 11:07 |
| blackflow | V7: it's not. mustn't be writable by anyone other than root | 11:11 |
| V7 | blackflow: somedir or internals ? | 11:11 |
| blackflow | somedir | 11:11 |
| V7 | So, it's not, isn't it ? 755 | 11:12 |
| blackflow | try 750 | 11:12 |
| tomreyn | "ChrootDirectory /somedir" for a directory located at /home/user/somedir seems incorrect to me. | 11:13 |
| V7 | tomreyn: Why home/somedir ? | 11:13 |
| V7 | Oh, I see, because output, I've sent to you | 11:14 |
| tomreyn | "ChrootDirectory %h/somedir" would probably work | 11:14 |
| blackflow | wait, is that /somedir or /.../somedir? | 11:14 |
| V7 | tomreyn: A directory is located in root | 11:14 |
| blackflow | the ChrootDirectory is path outside of the directory of course | 11:14 |
| V7 | blackflow: It's in root | 11:14 |
| blackflow | tomreyn: why? just chroot to user's homedir directly. | 11:15 |
| V7 | tomreyn: And output which you've seen there is little modified, so there's actually: | 11:15 |
| V7 | user@ubuntu:/$ | 11:15 |
| tomreyn | blackflow: that probbaly works, too. | 11:16 |
| blackflow | V7: make /somedir owned by root:user and of mode 750 | 11:16 |
| V7 | blackflow: The same | 11:17 |
| blackflow | V7: yeah that error is worded as if you can't have a chroot dir straight under root. Why not just make it /home/user ? | 11:17 |
| V7 | /home/user doesn't exist | 11:17 |
| blackflow | why not | 11:17 |
| V7 | Also, this /somedir is for mounted device | 11:17 |
| V7 | This /somedir musn't be changed | 11:18 |
| blackflow | well I don't know about chrooting to dirs straight under root, but that error message seems to imply you can't | 11:18 |
| blackflow | mount it under /mnt/somedir | 11:18 |
| V7 | Okay, I've changed it to /mnt/somedir | 11:18 |
| V7 | Copied stuff and now it's: https://hastebin.com/goriqazime.coffeescript | 11:21 |
| V7 | The same | 11:21 |
| blackflow | V7: please pastebin the output of ls -la /mnt/somedir . I especially want to see . and .. | 11:22 |
| tomreyn | and ChrootDirectory is /mnt/somedir now? (i dont think it follows symlinks if you have any) | 11:23 |
| V7 | blackflow: https://hastebin.com/ifaqotosib.rb | 11:24 |
| blackflow | great, and the ChrootDirectory is /mnt/somedir/ as tomreyn asked? And you restarted sshd of course? | 11:25 |
| V7 | tomreyn: Yes, sshd_config: https://hastebin.com/wiyoguweso.nginx | 11:26 |
| blackflow | V7: ugh, why password auth..... just say no! :) | 11:26 |
| V7 | blackflow: For testing | 11:26 |
| V7 | Yes, sshd was resarted | 11:27 |
| blackflow | V7: so, you restarted sshd (ssh.service) just to make sure, and it still throws the same mode/ownership error? can you pastebin the error? it lists the path element it dislikes | 11:27 |
| tomreyn | ls -la would not output this with trailing slashes, so you must have run something else there: https://hastebin.com/ifaqotosib.rb | 11:27 |
| V7 | It says: sshd[1387]: fatal: bad ownership or modes for chroot directory component "/" | 11:27 |
| V7 | tomreyn: Yes, dir1 and dir2 has data | 11:28 |
| blackflow | uh, can you pastebin the output of stat / ? | 11:28 |
| V7 | blackflow: https://hastebin.com/higetamagi.http | 11:29 |
| blackflow | how did that happen :) | 11:29 |
| blackflow | your root is owned by "user" | 11:30 |
| V7 | oh dear | 11:30 |
| jamespage | coreycb: working ceilometer py3 (needed it for networking-odl) | 11:30 |
| V7 | root is owned. | 11:30 |
| blackflow | well according to that pastebin, your root (/) is owned by "user" | 11:30 |
| blackflow | tht ain't gonna work. | 11:30 |
| V7 | of course | 11:30 |
| V7 | I'll reset it now | 11:30 |
| blackflow | how did that happen.... what's the ownership on other dirs under / ? | 11:31 |
| blackflow | like /bin, /usr, /etc, /root/, .... ? | 11:31 |
| V7 | Already reset all stuff | 11:31 |
| V7 | Give it some time to reboot | 11:31 |
| blackflow | didn't have to reboot tho' | 11:32 |
| V7 | blackflow: This will reset all changes | 11:32 |
| blackflow | how? btrfs/zfs snapshot? | 11:33 |
| V7 | Just a little tar archive of root | 11:35 |
| Ussat | just a little tar archive....... | 11:40 |
| V7 | Interesting | 11:40 |
| V7 | I've rebooted and the same. /'s owned by user. | 11:40 |
| V7 | This might be because of /etc/fstab | 11:41 |
| V7 | I'll check this now | 11:41 |
| V7 | blackflow: So, all directoried before chrooted one should be not writeable for a user which should be chrooted ? | 11:47 |
| V7 | s/sdirectoried/directories | 11:47 |
| V7 | So, /dir1/dir2/dir3/dir4 all should be 755 ? | 11:48 |
| blackflow | it really is all neatly explained in the frist few sentences of the ChrootDirectory option in the manpage :) | 11:48 |
| V7 | If chrooting to dir4 | 11:48 |
| V7 | Yes, I've seen | 11:48 |
| V7 | aufs / aufs defaults 0 0 | 11:48 |
| blackflow | "all components of the pathname are root-owned directories which are not writeable by any other user or group". That's the second sentence of the paragraph. | 11:49 |
| V7 | All components of the pathname must be root-owned directories that are not writable by any other user or group. | 11:49 |
| V7 | All components of pathname | 11:49 |
| blackflow | so.... ALL compnents of the path..... ROOT owned...... not writeable by any other user or group. | 11:49 |
| V7 | This is what it mean, all units of pathname | 11:49 |
| V7 | means * | 11:49 |
| blackflow | so that answers your question. :) | 11:49 |
| blackflow | so, of the chroot dir. NOT the dirs UNDER the chroot. | 11:50 |
| V7 | Yup, thank you very much blackflow | 11:50 |
| V7 | oh | 11:50 |
| V7 | You mean, dir1 can be 777, but dir1/chroot should be 755 ? | 11:50 |
| blackflow | yes, you can have whatever under it, but naturally, accessible/writable-where-needed to the "user" that's logging into that chroot. | 11:50 |
| blackflow | V7: it can be anything, under the chroot. | 11:51 |
| V7 | Understood | 11:51 |
| V7 | Hope you'll be okay there blackflow | 11:51 |
| blackflow | but chroot iself, the directory turned into "/" for that login session (aka the chroot), must be root owned, not writable by anyone else. | 11:51 |
| blackflow | why wouldn't I :) | 11:51 |
| HyP3r | Hello I'm searching for Ubuntu server a good tool which is auto remounting samba shares. I have the problem that our Windows File Server sometimes reboots and then my mounted shares are not mounted anymore. Last time I had the problem that the Ubuntu server booted and the Windows File Server was not running. In this case it would be cool if the server is retrying to mount the share consistently | 12:14 |
| ahasenack | morning | 12:20 |
| V7 | Interesting | 12:21 |
| HyP3r | lel | 12:21 |
| V7 | Now all works. SSHD is diabled. SFTP works well, but when I'm trying to authorize via SSH it says: "Could not chdir to home directory /mnt/somedir/: No such file or directory" | 12:21 |
| V7 | ssh is diabled * | 12:22 |
| V7 | disabled ** | 12:22 |
| V7 | ... but a directory exists: https://hastebin.com/opowupehiy.scala | 12:24 |
| ahasenack | rbasak: hey, question about git ubuntu merge workflow | 12:31 |
| ahasenack | cpaelzer: you too are welcomed to chime in :) | 12:31 |
| rbasak | o/ | 12:31 |
| V7 | So ChrootDirectory tries to chroot into $h/chroot rather then /chroot firstly ? | 12:33 |
| V7 | Even if ChrootDirectory /chroot is set | 12:33 |
| ahasenack | oh, sorry, left you hanging | 12:35 |
| ahasenack | ok | 12:35 |
| ahasenack | rbasak: what if our delta includes an upstream version bump? | 12:35 |
| ahasenack | rbasak: when I'm in the phase where I git reset HEAD^ and deconstruct the update into individual commits, | 12:36 |
| ahasenack | rbasak: I will have a lot of non-debian/ files and directories in there, reflecting the version bump | 12:36 |
| ahasenack | should I put all of those under "New upstream version: x.y.z"? | 12:36 |
| ahasenack | or just leave that particular commit as is, without deconstructing it? | 12:36 |
| rbasak | Let me check the definitions to give you an answer that's consistent with documentation | 12:37 |
| ahasenack | I might have used "deconstruct" incorrectly, maybe it's "reconstruct". I'm never sure | 12:39 |
| ahasenack | it's the first old/debian rebase you do after merge start | 12:39 |
| rbasak | ahasenack: which numbered step is that at https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow please? | 12:42 |
| cpaelzer | ahasenack: reading backlog ... | 12:43 |
| ahasenack | rbasak: 3.1.3-5 | 12:43 |
| rbasak | Got it, thanks. | 12:44 |
| rbasak | Your suggestion is right | 12:45 |
| rbasak | "should I put all of those under "New upstream version: x.y.z"?" | 12:45 |
| blackflow | V7: "no such file or directory" probably refers to the shell binary which doesn't exist in the chroot | 12:45 |
| rbasak | Yes - stuff all changes not in debian/ into one commit (assuming 3.0 (quilt)) | 12:45 |
| ahasenack | rbasak: the new upstream version fixed two bugs | 12:45 |
| cpaelzer | or is it really a version bump and not a quilt patch? | 12:45 |
| ahasenack | rbasak: group that all together | 12:46 |
| ahasenack | cpaelzer: rbasak it's a real version bump, we went ahead of debian | 12:46 |
| rbasak | Yes | 12:46 |
| ahasenack | * New upstream version: | 12:46 |
| ahasenack | - Fix database corruption bug when upgrading from samba 4.6 or lower | 12:46 |
| ahasenack | AD controllers (LP: #1755057) | 12:46 |
| ahasenack | - Fix security issues: CVE-2018-1050 and CVE-2018-1057 (LP: #1755059) | 12:46 |
| rbasak | Per upload, that is | 12:46 |
| ubottu | Launchpad bug 1755057 in samba (Ubuntu) "Samba 4.7.4 should not be shipped as an AD DC" [High,Fix released] https://launchpad.net/bugs/1755057 | 12:46 |
| ubottu | Launchpad bug 1755059 in samba (Ubuntu Bionic) "Samba [Bug 13272] [SECURITY] CVE-2018-1057" [High,Fix released] https://launchpad.net/bugs/1755059 | 12:46 |
| ahasenack | so stash non-debian diff under that commit? | 12:46 |
| cpaelzer | so it is not keeping debians tarball and adding a qduilt patch and instead really bumped the versions | 12:46 |
| rbasak | So for each upload, you may have up to one commit containing all non-debian/ changes | 12:46 |
| rbasak | Plus the other usual ones | 12:46 |
| ahasenack | yes, it's a new orig tarball | 12:46 |
| cpaelzer | yep I'd still group into one | 12:46 |
| cpaelzer | which shoud match the diff of the two orig tarballs | 12:47 |
| ahasenack | y | 12:47 |
| rbasak | You could split it further in theory. It wouldn't cause a problem for the workflow, but it'd be additional work to do and you don't need to go to that depth. | 12:47 |
| cpaelzer | in case you have it split already ... | 12:48 |
| rbasak | You'll be throwing away this one commit in the next step anyway | 12:48 |
| coreycb | jamespage: seems to make sense. is there a package done i can look at? | 12:48 |
| cpaelzer | like when the bump was made not from tarball but from git | 12:48 |
| cpaelzer | then you could keep it if you want | 12:48 |
| rbasak | The only purpose in keeping it now is that it means that the result of the deconstruct step can easily be checked. | 12:48 |
| cpaelzer | but I also see coming that you'll drop it anyway ont he merge | 12:48 |
| ahasenack | ok, thanks guys | 12:49 |
| cpaelzer | the only pain would be if this was bumped via git-commits and Debian moved with the upstream tarball - sometimes git!=tarball | 12:49 |
| cpaelzer | so ensure the orig tarball matches | 12:49 |
| ahasenack | this is one of those fun tarballs, with an empty directory | 12:49 |
| cpaelzer | yay | 12:49 |
| ahasenack | why make it easy, heh | 12:49 |
| cpaelzer | ahasenack: are you moving even further by the merge | 12:50 |
| cpaelzer | so if Debian was 1, we moved to 2 and he merge is now 3 ? | 12:50 |
| coreycb | jamespage: i'm thinking about not merging congress. congress bundles antlr3 which is not ideal, and there's a bug open upstream. zigo modifies the orig tarball to drop all of the antlr3 code, but i'd prefer to just use the published orig tarball. | 12:50 |
| cpaelzer | then the concerns on matching tarballs don't matter | 12:50 |
| ahasenack | cpaelzer: no, this one has a debian tarball | 12:50 |
| ahasenack | going from 4.7.x to 4.8.x | 12:50 |
| ahasenack | debian never released a 4.7.6, and told me they never would | 12:50 |
| ahasenack | they went from 4.7.4 to 4.8.x | 12:51 |
| cpaelzer | ahasenack: but that is fine, you will now move to 4.8.x and use theirs | 12:51 |
| ahasenack | right | 12:51 |
| cpaelzer | good | 12:51 |
| ahasenack | so the actual merge is normal | 12:51 |
| ahasenack | it's the deconstruct phase that had this oddball | 12:51 |
| cpaelzer | honestly, it doesn't matter too much | 12:51 |
| cpaelzer | as rbasak said, it is mostly to check if old/new match what they should | 12:52 |
| cpaelzer | and later in logical to compare if all commits are retained | 12:52 |
| ahasenack | and exercise some muscles | 12:52 |
| cpaelzer | but since this one will be dropped it doesn't matter if it is one or 2k | 12:52 |
| ahasenack | it will be a huge commit indeed | 12:52 |
| cpaelzer | ahasenack: when I'm done with my current merge you can exercise some review msucles :-P | 12:52 |
| rbasak | You can add everything and then reset out just the debian/ directory | 12:53 |
| rbasak | Saves typing | 12:53 |
| cpaelzer | rbasak: I added plenty of updates to your merge list | 12:54 |
| cpaelzer | all that I thought worth discussing is added as comment's so it can be discussed as needed | 12:54 |
| rbasak | Thanks :) | 12:54 |
| hehsec | beep boop | 13:40 |
| hehsec | How do you guys go about hardening new server installs? | 13:41 |
| hehsec | and managing logs | 13:41 |
| hehsec | Other than the usual use keys not passwords, change the ssh port to nonstandard to keep from logs getting flooded with crap | 13:41 |
| rbasak | ahasenack, cpaelzer: what does Monday triage mean? Sat-Sun inclusive? | 13:42 |
| rbasak | Or Mon also? | 13:42 |
| cpaelzer | Fr/Sat/Sun | 13:43 |
| rbasak | OK thanks | 13:43 |
| cpaelzer | Definition; up to including the last workday | 13:43 |
| cpaelzer | that works for any day | 13:43 |
| cpaelzer | rbasak: also see check_dates in /snap/ustriage/current/lib/python3.5/site-packages/ustriage/ustriage.py | 13:46 |
| blackflow | hehsec: apparmor all the things, modify services to run unprivileged wherever possible, take advantage of systemd's security features for services | 13:53 |
| hehsec | Systemd comes with security features for services? | 13:54 |
| hehsec | O.o? | 13:54 |
| blackflow | hehsec: https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db04 and then some | 13:56 |
| hehsec | blackflow: damn | 13:59 |
| hehsec | blackflow: I never knew I could use systemd to manage appamarmour and selinux profiles on services | 14:05 |
| hehsec | Why do people hate systemd again? | 14:05 |
| genii | Probably mostly because systemd-networkd | 14:08 |
| hehsec | genii: blackflow Any suggestions for learning to automate configuration of linux machines? | 14:08 |
| hehsec | I'm learning to work with tools like osquery | 14:09 |
| blackflow | hehsec: ansible! | 14:11 |
| genii | mssh sometimes is useful | 14:13 |
| hehsec | blackflow: gah | 14:15 |
| hehsec | genii: neat | 14:15 |
| * leosilva lunch | 14:43 | |
| lahlfors | On an ubuntu server with no MTA currently installed, I'd like to arrange it so that regular users cannot send or receive mail, but UIDs < 1000 can send email to root (and only to root) which will be forwarded to an external address via a specified SMTP relay. What MTA would make this easiest to achieve? | 14:49 |
| rbasak | lahlfors: I prefer exim for that kind of level of customisation. I'm not sure about restricting sendmail by uid though. I'd check if that is possible first. | 14:59 |
| rbasak | lahlfors: I have a standard exim configuration I use for stub servers for which I only want root email sent to me and nothing else. | 15:00 |
| rbasak | lahlfors: https://paste.ubuntu.com/p/TBNgvPnnfP/ is what I use | 15:01 |
| rbasak | lahlfors: that should be trivial to adjust to use an SMTP relay. Not sure about the uid restriction. | 15:02 |
| rbasak | That doesn't stop users from sending out via SMTP directly. | 15:02 |
| lahlfors | rbasak, thanks, this looks very helpful! | 15:02 |
| rbasak | I think it might send _everything_ to me regardless of target address | 15:03 |
| lahlfors | I don't want to attempt to stop users from making outgoing SMTP connections. But I would like it to be difficult for users to arrange for any daemon on this machine to make an outgoing SMTP connection on their behalf | 15:03 |
| sdeziel | lahlfors: to prevent users from sending to SMTP directly: iptables -A OUTPUT -m owner --uid-owner 1000-65535 -p tcp --dport 25 -j REJECT | 15:03 |
| lahlfors | sdeziel, thanks, but that's not exactly what I want. I want to prevent local users from sending or receiving mail using the local MTA. Receiving should be easy (some config option). But sending? | 15:05 |
| sdeziel | lahlfors: that was only to prevent bypassing the MTA | 15:06 |
| sdeziel | lahlfors: for the MTA part, with postfix you'd use http://www.postfix.org/postconf.5.html#authorized_submit_users | 15:06 |
| lahlfors | sdeziel, now we're talking! That config option should do what I need if I use postfix. Thanks. | 15:07 |
| sdeziel | lahlfors: for other MTA, a hack would be to use to use file ACLs to prevent executing the sendmail binary itself | 15:08 |
| lahlfors | Is postfix a good "lightweight" option in general? I have configured lots of servers but stopped installing MTAs long ago and only ever used sendmail and qmail | 15:08 |
| sdeziel | lahlfors: beware that most MTA will let someone directly talk to 127.0.0.1:25 and let you relay with it | 15:08 |
| lahlfors | sdeziel, I'll handle that with iptables restrictions on the loopback interface. Not sure if I need to worry about a unix socket file somewhere, too | 15:09 |
| sdeziel | lahlfors: postfix is pretty light IMHO. You can tune it even more if you disable inet services | 15:09 |
| runelind_q | oh hey Landscape upgraded cleanly from 17.03 to 18.04 | 15:11 |
| rbasak | lahlfors: looks like exim has $originator_uid and you can set up an ACL on that | 15:15 |
| rbasak | sdeziel: I would just grab a copy of the sendmail binary from somewhere else and run that :) | 15:16 |
| lahlfors | rbasak, great, you beat me to it. (Was looking for exim analogue of authorized_submit_users) | 15:17 |
| sdeziel | rbasak: ouch :) | 15:17 |
| lahlfors | geeze exim ACLs are complicated. I guess mail is just fundamentally complicated. ugh | 15:20 |
| teward | yes mail is complicated | 15:21 |
| teward | it has its own set of chaos tied to it, especially from a security perspective. | 15:21 |
| lahlfors | Basically, I don't want get in the mail business anyway. But it would be nice to aggregate cron emails and other problem reports at an external address | 15:22 |
| lahlfors | Right now problems detected in cron jobs are just ignored because no MTA is installed. A few manually send their output via amazon SES, but I don't want to be forced to configure that on each job, so I am looking into a very restrictive MTA config | 15:23 |
| rbasak | The main security issues with mail are spam and open relays | 15:28 |
| rbasak | My exim config attempts to avoid that by overriding everything to me, so it shouldn't be possible for someone to route anything anywhere else. exim's router mechanism is quite clear about the outcome there so hopefully no confusion. And I turn off listening on public interfaces, so I don't have to worry about SMTP ACLs. | 15:29 |
| rbasak | (even if someone did manage to get to my exim's SMTP all they'd be able to do is send emails to me since everything redirects to me) | 15:29 |
| rbasak | IMHO this is the most minimal and perfectly acceptable config for servers that aren't supposed to have users logged in. | 15:30 |
| teward | rbasak: +1. But getting everything to behave can still be tricky, when it comes to interaction with other mail servers and such | 16:49 |
| teward | whether the config is 'perfect' or not. | 16:49 |
| rbasak | teward: the point of my arrangement is that it doesn't really talk to other mail servers. Only my one :) | 17:30 |
| rbasak | Well, not even "really". It just doesn't! | 17:30 |
| teward | indeed. | 17:31 |
| madLyfe | so when i did a fresh install of server 18.04 and did a second reboot(had to reboot again after i left the installer usb attached. shouldnt this be aware and pass over it?) it booted up and didnt show 'server login:' it was just a blinking line. i ran 'sudo reboot now' and it then asked me to login. what im getting at is it wasnt very clear where it was at after the boot up. | 19:08 |
| madLyfe | https://usercontent.irccloud-cdn.com/file/VOeccHM5/image.png | 19:08 |
| madLyfe | not sure if that is a bug or feature request? | 19:09 |
| sarnold | probably not much to be done about it | 19:13 |
| madLyfe | pretty sure it used to just land you at a login prompt. not just empty blinking cursor. | 19:14 |
| sarnold | it did | 19:14 |
| sarnold | look up at the tty1 line .. | 19:14 |
| sarnold | there's your login: prompt | 19:14 |
| sarnold | async tasks run during boot may emit content nearly forever.. | 19:15 |
| madLyfe | hmm | 19:15 |
| ahasenack | how do I link debian merge bugs with the report in http://reqorts.qa.ubuntu.com/reports/ubuntu-server/merges.html ? | 19:40 |
| ahasenack | an example is dovecot's entry there, it's pointing at https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/1771524 | 19:40 |
| ubottu | Launchpad bug 1771524 in dovecot (Ubuntu) "Merge dovecot 2.3.x for Cosmic" [Undecided,Incomplete] | 19:41 |
| ahasenack | but that bug has no special tag about it | 19:41 |
| lopta | Right, let's see how big this Ubuntu Server thing is. | 21:48 |
| lopta | 1,162 MB (i386, 16.04.4). That's great. | 21:59 |
| lopta | I'll try 18.04 next. | 21:59 |
| tomreyn | ? | 22:01 |
| dpb1 | he's downloading over carrier pigeon | 22:07 |
| tomreyn | :) | 22:11 |
| genii | RFC 1149 | 22:11 |
| JanC | carrier pigeons can transport quite a lot more than that at impressive speeds :) | 22:37 |
| JanC | e.g. if you let them carry some 256GB (and bigger capacity?) micro-SD cards | 22:39 |
| * sarnold wonders what the airspeed velocity of RAICP carrying a RAID array is.. | 22:39 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
