[00:17] <BlenderPro> I connected to ftp server on windows from ubuntu using the command line ftp command I did succesfuly logged in but I'm stuck, can't upload full directories can someone help me
[00:20] <sarnold> BlenderPro: how are you trying to upload the directory? have you set the binary mode? are you using correct active or passive mode?
[00:20] <sarnold> man I forgot just how terrible ftp is..
[00:21] <BlenderPro> I am using binary mode set with type but I don't know about passive or active
[00:21] <sarnold> can you put a single file alright?
[00:21] <sarnold> does it come through uncorrupted?
[00:21] <BlenderPro> I can probably do that k I'll try
[00:22] <BlenderPro> I have a question before
[00:23] <BlenderPro> if I transfer a zip file should I go binary or ascii
[00:23] <sarnold> binary
[00:23] <BlenderPro> wow thanks
[00:23] <sarnold> ascii changes the line endings of files
[00:23] <sarnold> which will destroy nearly everything
[00:25] <BlenderPro> ok I tried put and send command and I get permission denied on both
[00:25] <BlenderPro> i try mkdir urt to create that directory and it can
[00:26] <BlenderPro> I check on windows server and it has permission for files to be written for that lone ftp account
[00:29] <sarnold> hmm, is the error perhaps coming from the local client rather than the remote server?
[00:29] <JanC> sounds like you have an issue with Windows or the FTP software on it?
[00:29] <sarnold> once you've logged in via ftp is the current working directory correct?
[00:30] <BlenderPro> sarnold, the current working directory is the root directory of the ftp account or my local directory
[00:31] <worm5er> Anyone online good with doing preseed partitioning schemes that I can discuss some challenges with?
[00:31] <BlenderPro> and yes I think is a local error since the server termianl is not showing me any error other the previous command typed that was succesful
[00:32] <JanC> BlenderPro: does your Ubuntu user have the rights to read those files?
[00:34] <BlenderPro> it doesn't
[00:34] <BlenderPro> is owned by root oh I missed that
[04:17] <ShaRose> so, TIL if you ever install a linux image with --no-install-recommends, install the extra package
[04:17] <ShaRose> because the stock package doesn't have such helpful features such as usb hid support. or networking.
[04:18] <sarnold> hah I've screwed that up before too
[04:18] <sarnold> filed the panicky bug report and all
[04:18] <ShaRose> sarnold yeah, I was testing my 'install ubuntu to zfs root' walkthrough
[04:18] <ShaRose> the guy who wrote the original never included it either
[04:18] <ShaRose> it works in a VM
[04:18] <ShaRose> tried it out on my hardware for the first time
[04:18] <ShaRose> it's not on the network. I can't log in with the terminal.
[04:18] <ShaRose> Mouse doesn't move, keyboard doesn't work
[04:19] <ShaRose> reinstalled it like 5 times
[04:19] <ShaRose> I could chroot in and do stuff, installed a BUNCH of extra packages I didn't need
[04:19] <ShaRose> man, when I could log in as root....
[04:20] <ShaRose> I was so relieved I took a massive dump
[04:21] <sarnold> hehehehe
[05:17] <hallyn> dannf: i didn't look too closely at the diffs - how much did you have to massage them?
[08:37] <caribou> rbasak: regarding the kexec-tools merge comments, how do you want to proceed with the changes I applied ?
[08:37] <caribou> rbasak: should I create new commits for the changes or include them in the existing logical commits & do a forced update of my git branch ?
[09:34] <rbasak> caribou: that's a very good question. Since you are an uploader, for the process generally I don't mind. The idea would be that when you're happy, you push whatever set of commits based on debian/sid, tag it upload/<version>, and the importer will figure it out. So no need for an MP. But to exercise the process, for sponsors, and when uploaders want a review, we want an MP. In that case, when
[09:34] <rbasak> reviewing, I think I'd prefer to see extra commits on the end, because then it's easier to re-review just the review fixes rather than the whole thing again. And in this case, I think it's fine to push those without rebasing again, since that's not really any different from uploading an ubuntu2 to fix things later. The person to merge next time will take care of squashing it down.
[09:35] <rbasak> OTOH if the review really wants a rework than a few minor changes, then perhaps rebasing would be better. In both cases I'm interested to see what Launchpad does to the MP.
[13:20] <caribou> rbasak: well, I have rebased the change so let see what it does
[13:21] <caribou> rbasak: I have another question : how did you define that the first cherry-pick needed -m2 as an option ? Looks like I don't need it for corosync
[13:56] <ddellav> coreycb lp:~ddellav/ubuntu/+source/openstack-trove
[13:57] <ddellav> ready for review
[13:59] <rbasak> caribou: see nacc's post to the ubuntu-server ML. Each imported commit can have up to two parents - the "changelog parent" and the "publishing parent". You want to find the changelog parent each time. -m selects the parent. I examined "git log --oneline --graph" to tell you which parent to use for each one.
[14:00] <rbasak> caribou: nacc's newest tool should do this automatically now.
[14:00] <rbasak> (as in, there's a tool that you can use to do this step and pick the right things and right parents to cherry-pick automatically)
[14:01] <caribou> rbasak: ah, ok
[14:01] <coreycb> ddellav, looks good, I've pushed that to the repo
[14:01] <ddellav> coreycb ok i'll trigger a rebuild in ci
[14:01] <coreycb> ddellav, ok
[14:57] <Yuri4_> Hi, guys! I have 2 servers. Server1 is mater server for WordPress site. Ocasionaly server1 will go down. Traffic manager will redirect visitors to server2. How do I keep wordpress in sync across two servers? I can use intermidiary folder via SMB 3.0. But, that's about how far I could plan it.
[15:11] <teward> does anyone know where Dovecot stores file attachments to emails when it's in imap format?  Does it store them as raw bytes in the mnox itself, or...?
[15:21] <andol> teward: The last time I checked it didn't do anything special with the attachments. Yet, seems simple enough to check for yourself?
[15:21] <RoyK> teward: afaik it uses maildir format (imap is a protocol, not a format), and with maildir, all mesages are stored in separate files. attachments are not separated from the message
[15:27] <teward> RoyK: this one's configured for mbox, does that still apply?
[15:28] <andol> RoyK: Well, Dovecot can use a bunch of different storage formats: http://wiki2.dovecot.org/MailboxFormat. Technically one even being imap, even if I don't think that was what was meant.
[15:29] <teward> andol: i meant how it would store the attachments in the mbox format, not in the protocol
[15:29] <teward> but point doesn't change, I still have to figure out whether it's storing attachments in the mboxes (inbox mailbox) or if it's storing it in directories
[15:30] <andol> teward: Just look in the files, and you'll. Also, I'm almost entirely certain that the attachment is stored as part of the message.
[15:30] <ogra_> they are usually uuencoded inside the single mail
[15:30] <ogra_> no matter if it is mbox or maildir
[15:31] <teward> andol: I'll have to get permission from the manager to dig around in there, I was hoping that was the case though
[15:31] <teward> ogra_: that's what I thought as well, but doesn't hurt to ask
[15:31] <RoyK> teward: mbox is jut one huge file with every message in that file
[15:32] <RoyK> teward: mbox scales horribly badly
[15:32] <teward> RoyK: yes, it does.  I didn't set this up heh
[15:32] <teward> but i think i have the answer I need
[15:32] <teward> :)
[15:32] <teward> thanks
[15:32] <ogra_> you can convert it
[15:32] <RoyK> np
[15:44] <teward> y'know, that would explain some of these MBOX files being 32GB+ in size, if it's all attachments lol
[15:44] <teward> if it's stored in the message heh
[15:47] <RoyK> teward: convert it to maildir - it'll help a bit
[15:47] <teward> RoyK: first task: get it from an ancient 9.04 to a newer 14.04
[15:47] <teward> s/9.04/9.10/
[15:47] <RoyK> hehe
[15:47] <teward> RoyK: gotta move everything and get it working
[15:47] <teward> THEN we can worry about maildir conversion lol
[15:47] <RoyK> first upgrade to 10.04, it should be easy with the right repos
[15:48] <RoyK> then do-release-upgrade to 12.04, then to 14.04
[15:48] <RoyK> or perhaps the quickest way - setup a new vm and install the needed software and move the data :P
[15:49] <teward> RoyK: doing the last one
[15:49] <teward> actually tried the first route; didn't work well
[15:49] <teward> E:BOOM
[15:49] <teward> so...............
[15:49] <teward> yeah
[15:49] <teward> doing it the old manual way
[15:49] <teward> with rsyncs to get mailboxes, user homedirs moved
[15:49] <teward> manually porting the configs over to newer dovecot...
[15:49] <teward> and testing during the next maintenance period >.<
[15:53]  * jrwren twitches thinking about old mail servers adn large mbox
[15:54] <teward> jrwren: fun-fact: I've been doing this for some time now heh
[15:54] <jrwren> teward: 20+yrs I'll bet ;]
[15:54] <teward> jrwren: well, i meant this project ;)
[15:54] <teward> i'm not *that* old :P
[15:55] <jrwren> oh. well, I am :p
[15:55] <teward> jrwren: indeed, and I admit when I don't know things... oh wait, this is what IRC and Internet support is for :)
[15:56] <jrwren> teward: sounds like a nice area ready for lots of improvement and improvement is fun.
[15:56] <teward> jrwren: first rule of IT: you can't know everything
[15:56] <teward> second rule of IT: you will always learn new things
[15:56] <teward> third rule: don't anger sysadmins, they have evil vengeful wrath
[15:57] <jrwren> fourth rule: sysadmins are worse than lawyers, treat them as shakespear would.
[15:57] <teward> heheh
[15:57] <teward> fifth rule: cryptolocker sucks, if you get it, RUN
[15:57] <teward> (in windows enviros)
[15:57] <RoyK> https://xkcd.com/705/
[15:58] <RoyK> (about sysadmins)
[15:58] <jrwren> lol
[16:01] <coreycb> ddellav, neutron should be back in shape, it needed a new oslo.cache.
[16:02] <ddellav> coreycb why did it build successfully locally? Am I not checking out the right repo or something?
[16:02] <ddellav> sbuild, yakkety, master branch
[16:02] <teward> RoyK: lol
[16:03] <RoyK> teward: not run - just restore from backup ;)
[16:03] <teward> RoyK: unless the backups are also crypto'd
[16:03] <coreycb> ddellav, I'm guessing you didn't use a snapshot orig tarball based on the latest upstream commits
[16:03] <jelly> s/RUN/restore from backups/;
[16:03] <teward> heard that happened to someone recently :P
[16:03] <jelly> hah
[16:03] <RoyK> teward: I've seen that happen
[16:04] <RoyK> teward: with people just finding out "oops - my x months old data has been overwritten"
[16:04] <teward> heheh
[16:04] <ddellav> coreycb ah ok. *facepalm*
[16:04] <coreycb> ddellav, heh
[16:05] <jelly> teward: it happened to $employer with a machine from someone in upper mgt who had access to LOTS of file server dirs.  Whoops, restore tens of thousands of files for 3 days.
[16:05] <coreycb> ddellav, btw for trove it looks like it might just need more patches rebased
[16:05] <ddellav> coreycb ok, when I ran quilt push -a it only showed 1 patch that had a single fuzzy match so i fixed that.
[16:06] <ddellav> coreycb but again, that was using the master branch of the packaging repo instead of the latest tarball
[16:06] <ddellav> so i will look again
[16:06] <coreycb> ddellav, hmm. oh so same situation probably.  you'll need to generate the snapshot tarball.
[16:06] <coreycb> ddellav, yeah, use master branch + snapshot tarball
[16:59] <blizzow> I'm doing an upgrade from 15.10 to 16.04.  The upgrade hangs during udev installation.  It hangs when trying to add the group 'input'.  If it exists, it complains that the group exists and says "Exiting." and sits. If the group doesn't exist, it adds the group says "Done." and never moves on. Anyone know how I can get past this? It's a real pain in the junk.
[17:36] <dabaR> Hello. I'd like to change the server's hostname so that the prompt is different. Or does just changing prompt pattern in .bashrc seem like a better idea for that? What kinds of things does server hostname affect?
[17:37] <sdeziel> dabaR: if you only care about the prompt, I'd only change PS1 in your ~/.bashrc. It's much less intrusive than changing the hostname
[17:38] <dabaR> Thanks
[17:49] <blizzow> ugh xenial upgrading is so brutal! freezes while removing console-common, freezes while upgrading udev, errors processing the lvm2, mdadm, lybsystemd, systemd, console-setup-linux. Whoever decided that 16.04 should be released with a completely b0rked upgrade path to wait until 16.04.1 should be tarred, feathered, and ridden out of the community on a rail.
[17:51] <jelly> what else should have they done, considering noone did the work to fix said upgrade path?
[17:51] <blizzow> Oh, and whoever decided that UTC should be removed as a timezone choice during installation should be put in a stockade and prodded with hot pokers.  Choosing Iceland as your location totally screws the installation language.
[17:51] <dabaR> So you're saying you upgraded before 16.04.1 against explicit warning?
[17:54] <blizzow> dabaR: I got a notice saying that a new release was available, there was no explicit warning during the release process.  I shouldn't have to come to IRC and/or scour the web for "explicit" warnings as such.
[17:54] <blizzow> jelly: If the work was going to eventually be done (to release 16.04.1), then the whole release cycle should have started at that point. In any case "STABLE" should not be released with a broken upgrade path.
[17:54] <blizzow> I'd understand unstable having a broken upgrade path, but stable? c'mon.
[17:55] <jelly> ok, so you think they ought to have delayed the release to 16.07?
[17:55] <dabaR> blizzow: mine did not. I tried upgrading a 14.04 a week or so ago, and it told me nothing is available
[17:55] <dabaR> Then I googled, cause I knew it was available, and then I found some mention of not recommending upgrade
[17:56] <jelly> what's the alternative you're proposing there, except for "magically conjure engineers to fix do-release-upgrade in time"
[17:56] <dabaR> How did you upgrade? with do-release-upgrade, or?
[17:56] <sdeziel> dabaR: that's because LTS only offer to upgrade to the next LTS when it has reached the .1
[17:56] <dabaR> Sorry to hear about your server, BTW
[17:56] <dabaR> Ah, so blizzow upgraded from something that was not the LTS?
[17:56] <sdeziel> I would think so
[17:57] <jelly> I've done a trusty->xenial myself, with the appropriate option given to d-r-u but I did not complain about breakage because it's KNOWN to be broken
[18:00] <blizzow> jelly: my alternative is not to release something labeled stable LTS until it's damn well good and ready.
[18:01] <dabaR> blizzow: did you upgrade from 14.04, or which version?
[18:01] <blizzow> Done both 14.04 and 15.10.
[18:02] <\9> 14.04 doesn't let you upgrade to 16.04 without using the -d switch, which is a well documented debug option
[18:03] <jelly> blizzow: it was well good and ready for the initial installations, and it was well documented when release upgrades would be ready
[18:04] <genii> It's not a bug. LTS to LTS option should not kick in until after first point release
[18:05] <genii> If you used -d option on do-release-upgrade right now, it would take you to the development version which is Yakkety
[18:05] <jelly> genii: that does not cover the 15.10->16.04 upgrade tho
[18:15] <coreycb> beisner, ceilometer 1:5.0.3-0ubuntu1~cloud0 and keystone 2:8.1.2-0ubuntu1~cloud0 are ready for promotion to liberty-proposed
[18:16] <coreycb> beisner, and python-os-brick 0.5.0-0ubuntu3~cloud0 is as well
[18:18] <beisner> coreycb, ok those are promoted to liberty-proposed
[18:18] <coreycb> beisner, thanks sir
[18:18] <beisner> coreycb, yw sir :)
[18:54] <nacc> blizzow: i'm sorry you had a bad upgrade experience. As mentioned earlier by others, 15.10 -> 16.04 should work, if you could provide steps to reproduce or file a bug that would be great. 14.04 -> 16.04 is not supported (14.04 -> 16.04.1 will be), and none of the tools out there should be offering it by default.
[19:15] <newbsie> I setup basic firewall/ssh/fail2ban, but I can't login after a reboot. I followed these simple instructions http://dpaste.com/0MME0D9, anyone?
[19:15] <newbsie> Everything works until a reboot.
[19:17] <sarnold> newbsie: what error message do you get from the client? what's in the ssh logs on the server?
[19:17] <newbsie> sarnold: problem is, I can't get to the server now so I can't see the logs. From the client, there is just a time-out.
[19:18] <newbsie> sarnold: I tested the new account, and loggedin with a key fine, then did a sudo -i and configured the firewall, then reboot and dead.
[19:19] <newbsie> There are only two things I can think of that can go wrong, which is the firewall, and the fail2ban.
[19:19] <sarnold> newbsie: just hanging suggests that might be correct; when you netcat to port 22 on that machine do you get an ssh banner? (I expect nc to hang too)
[19:21] <newbsie> sarnold: yup, just hangs
[19:22] <sarnold> newbsie: is this on a cloud provider like amazon? perhaps you need to modify their security groups
[19:23] <newbsie> sarnold: well everything works before the configuration, so I assume it has nothing to do with the cloud provider.
[19:23] <newbsie> sarnold: is ufw, iptable based?
[19:23] <sarnold> newbsie: okay, I just wanted to make usre that you'd tried the login from elsewhere rther than just on the local machine :)
[19:23] <sarnold> newbsie: it is
[19:25] <newbsie> sarnold: did anything stand out in the directions as a culprit? disallowing root login, and password auth shouldn't have any effect... and the firewall rules seem to be correct. Stumped.
[19:26] <sarnold> newbsie: I thought perhaps the home directory or ~/.ssh/ directory ownerhsip/permissions might upset sshd but you're not even getting that far :/
[19:26] <sarnold> newbsie: there's always a chance that it's fscking or something similar.
[19:27] <newbsie> sarnold: I am playing around with this on DO, and this is like the 3rd time this happened, so something is wrong with the config I think.
[19:28] <sarnold> newbsie: do they provide a console?
[19:29] <newbsie> sarnold: interesting, the console works with a password login
[19:30] <blizzow> nacc: Thanks for the condolences. The 15.10 upgrade path seems to freeze around udev/systemd (on at least two systems). I have no idea what's causing the issue though. As I mentioned before, terminal output gives an error saying something along the line of: group Input exists already, exiting. If I remove that group and try again, it adds the group, says done. and does nothing else. I see nothing in apt logs, ps output shows that udev is trying to re
[19:32] <sarnold> newbsie: excellent! then you stand a chance of debugging this thing :)
[19:32] <sarnold> blizzow: you were cut off at "trying to re"
[19:32] <blizzow> trying to restart but I've let it sit overnight with no success.
[19:32] <sarnold> blizzow: I suspect the "group input" thing is a simple warniing that you can ignore
[19:34] <blizzow> I assumed so as well, but the hanging during upgrade is not something I can ignore.  Well, I can ignore it and reinstall from scratch on servers that fail upgrades, but jeez that sucks.
[19:35] <sarnold> where there more impressive looking messages higher up the scrollback?
[19:38] <newbsie> How do I verify the rules in ufw? When I do "ufw status", all I get is "Status: active". Every where else I look, it says it should show the rules....
[19:47] <newbsie> OMG, I'm retarded. I didn't add the OpenSSH rules... and thus, no rules are showing.
[19:49] <sarnold> d'oh
[19:51] <newbsie> sarnold: thank you for your help... live and learn.
[19:52] <sarnold> newbsie: all sorted? rebooted and everything? :)
[19:57] <newbsie> sarnold: yup!
[19:57] <sarnold> newbsie: nice :D
[19:58] <newbsie> sarnold: thank God for the cloud console
[19:58] <sarnold> newbsie: no kidding. some cloud providers don't have those consoles. I'm not sure how they survive. hehe.
[19:59] <newbsie> sarnold: it is the sliced bread of cloud feature
[20:00] <sarnold> hehehe
[20:33] <nacc> blizzow: I upgraded my home laptop from 15.10 to 16.04, and have tried it in a few containers, and not seen that. It's obviously possible something is specific to your configuration that is causing that issue, it would be good to file a bug report and see if we can narrow it down that way
[21:08] <cryptodan_mobile> newbsie: sudo iptables -L
[21:09] <newbsie> cryptodan_mobile: thanks! :)
[21:24] <teward> has anyone noted any weird apt/dpkg/systemd errors on package installations where dpkg fails because it gets an error code but the application is actually running when you check the status of the service?
[21:30] <nacc> teward: i could see that happening potentially, depending on which stage the error happened at?
[21:31] <cryptodan_mobile> teward: have an example
[21:32] <teward> sure, there's at lesat two nginx bugs that fit that criterion
[21:32] <teward> let me grab them
[21:32] <teward> https://bugs.launchpad.net/bugs/1588972 most recent
[21:33] <teward> another here: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1582954
[21:36] <OerHeks> 2nd one is for 16.10
[21:36] <nacc> teward: looking
[21:37] <teward> OerHeks: started in Xenial
[21:37] <teward> then Yakkety opened, kept going, same symptoms of bugs
[21:37] <teward> if it were a *real* bug, it'd be in the systemctl output
[21:37] <nacc> teward: have you been able to reproduced it yourself?
[21:37] <nacc> *reproduce
[21:37] <teward> nacc: no, that's the problem
[21:37] <nacc> teward: ack, was wondering
[21:37] <teward> and I have no specs on the systems observed
[21:38] <teward> (see my q in #ubuntu-devel)
[21:38] <nacc> teward: yep, noted
[21:39] <nacc> teward: do you know in the bugs (still reading them myself) that nginx is already running and that's why the systemctl fails?
[21:39] <teward> nacc: apport hooks for any package failure on install/upgrade pulls the full systemctl data, they should be in those bugs
[21:39] <teward> though, apport chokes with foreign characters
[21:39] <teward> (I think I filed a bug on it?)
[21:40] <nacc> teward: oh i see that now, sorry!
[21:41] <teward> nacc: you can blame Debian for my needing to pull that data - systemd and the nginx init scripts now just eat error data
[21:41] <teward> silently :P
[21:41] <teward> 'twas why I put the apport hooks in in the first place
[21:42] <nacc> sigh
[21:42] <teward> nacc: for all other reasons for installation failure...
[21:42] <teward> missing nginx.conf, port bind errors, configuration errors in conf files, obsolete conf arguments, etc.
[21:42] <teward> it's captured by the apport hooks
[21:42] <teward> these fails are nondeterministic
[21:42] <teward> and unable to be reproduced by myself
[21:43] <teward> even on 1 vCPU 128MB RAM systems which should choke
[21:44] <nacc> teward: yeah, based upon the systemctl log (and when it says the jobs started) it does seem like nginx was already installed
[21:45] <nacc> and running
[21:45] <teward> nacc: exactly why i'm thinking "WTFH"
[21:46] <nacc> the 16.10 one's apt ordering is also strange
[21:46] <teward> i think hggdh peeked at at least two of these
[21:46] <teward> *shrugs*
[21:46] <nacc> it seems like removing nginx-core removal would imply the others can't proceed
[21:46] <teward> nacc: i think i should explain nginx a little
[21:46] <teward> nginx-core is the flavor
[21:46] <teward> nginx-core == nginx-full minus third party modules
[21:46] <nacc> ah
[21:47] <teward> nacc: nginx-common has all the common files
[21:47] <teward> nginx-core, Conflicts: nginx-light
[21:47] <teward> nginx-light, Conflicts: nginx-core
[21:47] <teward> light, core, extras, full - the flavors of the package
[21:47] <teward> (different modulesets)
[21:47] <nacc> understood now, thanks!
[21:47] <teward> so the apt ordering there is valid and makes sense in that case
[21:47] <teward> but the failures don't
[21:48] <nacc> yep
[23:50] <atralheaven1> Hello, I have a question that I don't know where to ask. I have a vpn server, I would be glad to share it with others so they can get free of this censorship that we have. but I am worried about abuse, if someone uses my vpn to do illegal stuff etc that can get me in trouble, what can I do for that? thanks.