[09:58] <jdelers> where can i find the logs for apache2 web server
[10:00] <caribou> rbasak: just reviewed your comment on the clamav merge : looks like tests are running ok now so I'll drop the delta
[10:00] <caribou> rbasak: should I just force-push the new merge branch afterward ? look like it worked fine the previous time
[10:15] <hateball> jdelers: /var/log/apache2
[10:16] <jdelers> hateball:  what i need is where the console.log("something") will be displayed
[10:16] <jdelers> i cannot fins them written in the dir u have shown
[10:19] <mnms_> Hi guys
[10:19] <mnms_> i tried to fix "Diskfilter writes are not supported" error message If i can say like that
[10:19] <mnms_> and I turned off quick boot (to 0)
[10:19] <mnms_> now Im getting busybox with initramfs prompt
[10:20] <mnms_> any ideas what could happened ?
[10:22] <rbasak> caribou: yes, that worked. I think we can have a choice in the workflow - for simple things just push another commit on the end, and for more complex things where squashing things down would be easier for a re-review then tag a merge.v1 (or v2, etc) and force push an update. In this case I think adding a single commit to the end is fine.
[10:22] <rbasak> The advantage of adding commits is then I just have to review the commits added against my previous comments, trusting my previous review.
[10:22] <caribou> rbasak: that's what I also thought. will do that & update the MP
[10:23] <rbasak> But for complex changes, sometimes it's easier to re-review the entire thing, in which case squashing everything down and rebasing is easier.
[10:23] <rbasak> caribou: thanks!
[11:55] <teward> rbasak: i'm going to start over with the merge from Debian, and prep some packages for testing via PPA - and then make a call for testing on the Server mailing list.  Do you want me to reply to the pagespeed inquiry in so much that they can check with me if there's going to be a version bump/change in the pipeline?  (I'm usually on the ball with security updates too)
[11:56] <teward> ^ for nginx
[11:56] <teward> ('cause i broke something I think)
[12:00] <rbasak> teward: sure, introduce yourself :)
[13:54] <coreycb> jamespage, libvirt 1.2.12-0ubuntu14.4~cloud1 is ready to promote to kilo-updates
[13:55] <coreycb> jamespage, also, horizon 2:9.0.1-0ubuntu2~cloud0 is ready to promote to mitaka-updates
[13:55] <jamespage> coreycb, libvirt doing now
[14:01] <jamespage> coreycb, ok all done
[14:01] <coreycb> jamespage, thanks
[14:41] <Haled> what's the proper way to make mdadm 3.3 boot degraded on 16.04?
[14:43] <hallyn> gaughen: do you know where users should report bugs against the official (I assume they are) canonical vagrant/vbox images?
[14:43] <hallyn> (hashicorp seems to claim canonical provides those - i'd never heard of that)
[14:43] <hallyn> there's a bug about ubuntu/xenial64 image taking a long time - on virtualbox, vagrant, on mint, reported against lxc.
[14:44] <hallyn> jamespage: ^ do you know?
[14:44] <Odd_Bloke> hallyn: Use the cloud-images project.
[14:44] <hallyn> Odd_Bloke: will do, thx
[14:44] <Odd_Bloke> hallyn: Thanks. :)
[14:45] <hallyn> hm, it says There is no package named 'cloud-images' published in Ubuntu.
[14:45] <hallyn> oh, project
[14:45] <Odd_Bloke> hallyn: https://bugs.launchpad.net/cloud-images
[14:45] <Odd_Bloke> :)
[14:45] <hallyn> done thx
[15:23] <jrwren> i was just chatting with someone doing a do-release-upgrade and had an idea...
[15:23] <jrwren> i wonder if we will ever see apt and servers support http2 so it can keep that connection open and not have to TCP slow start.
[15:31] <teward> doubt we'll see that any time soon, jrwren
[15:32] <jrwren> teward: unless someone REALLY scratches that itch, eh? ;]
[16:14] <nacc> rbasak: the more i think about it, the more i htink even SRUs for our team can use the imported tree
[16:14] <nacc> rbasak: it *should* be supported (upload/ tags) if we get those working, regardless of where they are found in the tree
[16:30] <JanC> jrwren: you can plug new protocol backends into APT (there already are HTTP, FTP, torrent, etc. backends), so write one yourself? :)
[16:31] <JanC> s/protocol/transport/
[17:27] <spm_draget> The 'mdadm' package is part of 'ubuntu-server'… at least 'apt-get purge mdadm' also suggests remove 'ubuntu-server'. So… I could just leave it installed even if I do not need it, no harm done. But when installing software, mdadm service will comlain every time that 'W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.'. How to get rid of that warning?
[17:30] <nacc> spm_draget: dpkg-reconfigure mdadm, iirc
[17:30] <nacc> tell it to not configure any arrays?
[17:30] <nacc> err, not start any
[17:33] <spm_draget> Okay, reconfigured it… the reconfiguring ended with the very same warning xD Oh well, we'll see if it fixed anything.
[18:33] <lochlann> whats the best/fastest method to transfer files from one external hard drive to another external hard drive on a headless ubuntu 14.04 server? Doing this is slow via samba. Hoping there is something faster.
[18:34] <patdk-lap> heh?
[18:34] <patdk-lap> exactly how do you transfer files via samba?
[18:34] <patdk-lap> why not just use rsync, or cp, or mv
[18:34] <nacc> spm_draget: fwiw, it's a harmless warning either way
[18:34] <spm_draget> nacc: I know. Just annoying :P
[18:34] <b1tpunk-work> attach usb external to headless server, ssh to server, mount usb drive, use mv or cp.
[18:34] <nacc> spm_draget: yeah :)
[18:34] <nacc> spm_draget: i had forgotten i see it, tbh
[18:35] <spm_draget> mdadm should not warn but info about an empty config. And I see no reason why it does when I install packages… but oh well
[18:35] <\9> I tend to use rsync with --checksum for large transfers, sure it takes much longer but I can be sure that nothing gets lost
[18:35] <nacc> spm_draget: i think it's a harder (internal to mdadm) problem to solve, sadly
[18:35] <nacc> spm_draget: it's update-initramfs' trigger that's complaining
[18:35] <nacc> spm_draget: afaict
[18:36] <lochlann> patdk-lap: via mounting the shared drives on another system through the samba network... but this method is slow
[18:36] <patdk-lap> I dunno why you would do that
[18:36] <patdk-lap> now your adding some kind of network and protocol overhead
[18:36] <patdk-lap> and samba is known to be very slow
[18:36] <lochlann> b1tpunk-work: hopefully this is much faster :)
[18:36] <patdk-lap> why microsoft is on version 3.2 of it, in attempts to speed it up
[18:37] <b1tpunk-work> lochlann: it should be much faster.
[18:37] <lochlann> patdk-lap: because certain devices need samba access to the server
[18:37] <spm_draget> nacc: That could very well be. And yeah, I can imagine the log-evel needs to be adjusted with mdadm upstream. *shrug*
[18:39] <nacc> lochlann: right, but devices needed samba access doesn't mean you need to use samba for copying files ?
[18:39] <nacc> *needing
[18:39] <nacc> lochlann: iiuc, you have two HDDs attached to a linux machine, that are shared over samba to a network, and you want to copy files between them on the Linux machine?
[18:40] <jrwren> is the answer? linux has a copy command, cp. use it.
[18:40] <lochlann> nacc: you are correct. one of the media drives is failing so I want to move the contents to another drive (not dd as there is other stuff on the target drive)
[18:41] <nacc> lochlann: right, so just use cp on the Linux machine? or rsync or whatever
[18:41] <nacc> lochlann: that has no relevance (afaict) to the samba side of things
[18:41] <nacc> lochlann: by which, I mean, the samba network will still see both drives, and the files on them (when and if they exist)
[18:41] <lochlann> nacc: I know I can... my question was for the best method / fastest way... I was not sure if using ssh to cp/mv was limited in speed over the internal network the way samba is
[18:42] <\9> cp only is limited by device i/o
[18:42] <nacc> lochlann: why would you use ssh? I thought you just said they are both connected to the same Linux machine?
[18:42] <b1tpunk-work> No, the copy isn't going over the ssh
[18:42] <b1tpunk-work> it would be a direct copy
[18:42] <lochlann> nacc: they are on the same machine.....
[18:42] <b1tpunk-work> you are attaching external storage to the box
[18:42] <nacc> lochlann: then why would you use ssh? :)
[18:42] <lochlann> nacc: to see the terminal
[18:43] <b1tpunk-work> The box is headless
[18:43] <nacc> lochlann: oh you mean you're ssh'd to the server?
[18:43] <nacc> lochlann: that has nothing to do with running `cp` on the server...
[18:43] <nacc> lochlann: ssh $server; cp [-R] /path1 /path2
[18:43] <b1tpunk-work> Original Problem Statement:  whats the best/fastest method to transfer files from one external hard drive to another external hard drive on a headless ubuntu 14.04 server? Doing this is slow via samba. Hoping there is something faster.
[18:43] <lochlann> when using samba I am limited in transfer speed due to network...... did not know if ssh into machine to cp/mv was affected this same way
[18:43] <nacc> lochlann: the `cp` itself is being executed on $server
[18:45] <lochlann> glad to know it isn't the same..... waiting on samba is tiring, LOL..... especially when I am talking about 3TB worth of data
[18:45] <b1tpunk-work> So, both HDDs are samba shares, he is access the server via samba though his machine, so the data is leaving the machine, going to his machine, only to go back to the source machine.... That is how this whole discussion spiraled
[18:45] <b1tpunk-work> lol
[18:45] <lochlann> lol
[18:46] <trippeh_> that would be the slowest way to do it, indeed.
[18:46] <nacc> wow, ok. But yes, this has nothing to do with samba, really. lochlann, afaict, your actual question boils down to how do I copy files from one drive to another remotely. And if you have ssh access, just ssh in and run `cp` :)
[18:46] <b1tpunk-work> Exactly what I told him.
[18:46] <lochlann> this makes my life simpler too.... now I can do it from any machine in the house.... only 1 machine has samba access so always having to come to that machine is a hassle, lol
[18:46] <patdk-lap> but cpu speed will slow down ssh a lot
[18:46] <patdk-lap> and even more if you use compression
[18:47]  * trippeh_ moved 40TB today
[18:47] <\9> patdk-lap: doesn't matter as far as the copy process is concerned though
[18:47] <patdk-lap> ah, depends
[18:47] <patdk-lap> use rsync to copy often, never samba
[18:47] <lochlann> one time copy :)
[18:47] <patdk-lap> samba is kindof slow, like max of 50MB/sec and maybe 80MB/sec over gigabit if your get lucky
[18:47] <lochlann> well, till the next drive decides it wants to die, LOL
[18:47] <trippeh_> patdk-lap: ssh to host, cp from drive a to drive b which both are on same host.
[18:48] <patdk-lap> if he can put them on the same host
[18:48] <patdk-lap> seems like he wasn't wanting to do that
[18:48] <patdk-lap> that should give >100MB/sec
[18:48] <patdk-lap> depending on file sizes
[18:48] <patdk-lap> and if usb2 is used or not
[18:48] <patdk-lap> if using usb2, there is just no hope
[18:49] <nacc> patdk-lap: my understanding is that physically, the two drives are already on the same host
[18:49] <b1tpunk-work> yes
[18:49] <b1tpunk-work> I believe that is a true statement
[18:49] <patdk-lap> they are? then what did samba have to do with this?
[18:49] <b1tpunk-work> OMG
[18:49] <patdk-lap> very confusing :)
[18:49] <nacc> heh
[18:49] <lochlann> ^ ^ :)
[18:50] <b1tpunk-work> From before: So, both HDDs are samba shares, he is access the server via samba though his machine, so the data is leaving the machine, going to his machine, only to go back to the source machine.... That is how this whole discussion spiraled
[18:50] <nacc> patdk-lap: yeah, hence the big loop :)
[18:50] <nacc> b1tpunk-work: my fault, sorry
[18:50] <b1tpunk-work> all good
[18:50] <b1tpunk-work> lol
[18:50] <b1tpunk-work> at least I wrote it out already
[18:50] <b1tpunk-work> caopy and paste
[18:50] <lochlann> all is solved :) no worries anymore lol
[18:50] <b1tpunk-work> copy even
[18:50] <b1tpunk-work> or cp
[18:51] <b1tpunk-work> to bring this shit full circle
[18:51] <lochlann> my fault.... should have worded the question differently
[18:51] <jrwren> we are so confused because it is not very often that a user is advanced enough to know how to setup samba, but beginner enough to not know how to copy files.
[18:51] <lochlann> I should have said something like .......     is ssh cp/my affected by local network overhead the same way samba is .....   then we wouldn't have had a bomb explode, lol
[18:51] <b1tpunk-work> Hey, even the most advanced users have brain farts fromtime to time
[18:52] <lochlann> jrwen: see my last statement
[18:52] <b1tpunk-work> lochlann: even that is confusing
[18:52] <lochlann> it wasn't a matter of not knowing how to do it.....
[18:52] <b1tpunk-work> lol
[18:52] <lochlann> lol
[18:52] <patdk-lap> I would recommend throwning nfs into the samba mix
[18:52] <b1tpunk-work> and cifs
[18:52] <lochlann> still better than orginal question though
[18:52] <b1tpunk-work> lol
[18:52] <nacc> lochlann: but you understand now why that is sort of a silly question? :)
[18:52] <b1tpunk-work> hell, why not afp too!! =P
[18:53] <patdk-lap> does anyone know how to use afp? :)
[18:53] <lochlann> nacc: the question itself wasn't silly.... the way I portrayed it was :)
[18:53] <b1tpunk-work> I do
[18:53] <b1tpunk-work> Unfortunately.
[18:53] <b1tpunk-work> Had a division office that HAD to be all Apple
[18:53] <b1tpunk-work> Why? I have no effing clue
[18:53] <b1tpunk-work> But that is what they wanted
[18:54] <nacc> lochlann: no, it sort of is. ssh puts you on a remote shell. Running commands there doesn't transfer the contents of files to your local machine. You are running those commands remotely.
[18:54] <b1tpunk-work> I am out all. Time to go home and drink beer all weekend!
[18:54] <lochlann> nacc: right, and that was what I was trying to find out.... just should have asked better
[18:54] <lochlann> thanks b1tpunk-work
[18:55] <lochlann> you need a beer after being able to understand my weird question, lol
[18:55] <b1tpunk-work> np lochlann
[18:59]  * jrwren uses afp and netatalk
[19:59] <JaguarDown> Hi all, I have a quick question about remote SSH.
[20:00] <JaguarDown> On Windows with putty you can skip putting in your private key passphrase by storing your key in putty agent and only input the passphrase once which later makes connecting pretty seamless.
[20:00] <JaguarDown> Is there a way to automate this when connecting from a linux terminal with openSSH?
[20:00] <patdk-lap> same on ubuntu
[20:01] <patdk-lap> but I haven't figured out why the agent doesn't run correctly on 16.04 by default
[20:01] <OerHeks> JaguarDown, openssh-keys, pawsswordless
[20:01] <JaguarDown> Okay now that you say that I vaguely remember.
[20:01] <OerHeks> https://help.ubuntu.com/community/SSH/OpenSSH/Keys
[20:02] <JaguarDown> I have an old box home server but it's been offline a while, I'm getting it back up. Haven't used my [beginner] linux skills in a while
[20:03] <JaguarDown> Thanks patdk-lap and OerHeks
[20:03] <OerHeks> after installing keys, and transferring to client, put in /etc/ssh/sshd_config PubkeyAuthentication yes and off you go
[20:07] <JaguarDown> Thanks
[20:19] <LeMike> Hello. I installed a samba service and it is running slow. Several pages on the web did not help. I can transfer to the server with 10 Mb/s but samba only gives me ~1M/s . It uses an usb drive but on this it can write with 22Mb/s. So I think the client is the problem. I am using cifs. Is it always that slow?
[20:20] <LeMike> Besides: The slow client runs Xubuntu. Testing with OSX the client can upload with ~4Mb/s (for a 128 Mb file).
[20:23] <patdk-lap> samba is slow, the protocol itself was not designed for speed
[20:24] <patdk-lap> but the speed shouldn't be compounded like that
[20:25] <LeMike> I would be happy about 10 M/s at least. And I don't get what is making the whole thing that slow.
[20:26] <jrwren> I've gotten 100MB/s on gigabit with samba, so it shouldn't be that slow unless you have crazy slow CPU.
[20:26] <patdk-lap> ya, if you have a good cpu, it will cap out at around 300MB/s
[20:26] <patdk-lap> normally cap out at 80MB/s on gigabit
[20:26] <patdk-lap> depends on what protocol your samba is using though
[20:28] <LeMike> The CPU of the server is just 1Ghz. I don't fix it to a specific protocol yet. Might be a first leverage. SMB2 or 3? After reading several settings for performance boost it is almost down to it's defaults besides minor changes to match the MTU
[20:30] <LeMike> (only smb and owncloud is running there, so it's mostly idle)
[20:32] <goddard> I need to create a vm and eventually move it to a vm server that is internet facing.  What software should I use to do this?  I need something relatively easy to manage and setup that will support web, db, and email.
[20:48] <ikonia> goddard: how do you expect to create a vm without a vm server ?
[20:49] <ikonia> or are you looking at transportable images ?
[20:50] <goddard> i was thinking I could create it on my workstation and move it over as the host machine will have to host the vm for a short period while I install the vm server software on the server
[20:50] <goddard> one 1 server exists but i can't have down time
[20:50] <goddard> dns servers are setup with 2 ip addresses so it makes it much easier
[20:51] <ikonia> goddard: you'll find it easier and simpler to create in situ on the target platform
[20:51] <goddard> no doubt, but not an option
[20:51] <goddard> only 1 server
[20:52] <ikonia> what has 1 server got to do with anything ?
[20:52] <goddard> how can i install new software on a system that is running the server that needs not to have downtime?
[20:52] <ikonia> don't wait until you have your second vm server
[20:53] <ikonia> then just install on the target, simple and easy and clean
[20:53] <goddard> i dont have a second server
[20:53] <ikonia> then how are you going to move it somehwere if you don't have somewhere to move it to
[20:53] <goddard> it is just a workstation that will run the vm for a short period so i can reinstall the OS on the actual server
[20:54] <ikonia> could you not just run the softrware on the desktop
[20:54] <ikonia> rather than make it more complex
[20:54] <ikonia> and then re-install the server and move the software bac
[20:54] <ikonia> back
[20:54] <ikonia> is there an actual requirement for a vm
[20:54] <goddard> yeah that is what i was planning
[20:54] <ikonia> or is it just "run the services while I reinstall"
[20:54] <ikonia> ok - so you don't need a vm then
[20:55] <ikonia> you just need to run the software
[20:55] <goddard> i just don't know what software would make most sense
[20:55] <ikonia> ??
[20:55] <ikonia> you must know the software you are running on the machine you need to re-install
[20:55] <goddard> yeah just run the services while i reinstall
[20:55] <goddard> i know what software and services i will run in the vm but I don't know which vm server software to use
[20:56] <ikonia> why do you need a vm
[20:56] <ikonia> can't you just run the services on the desktop
[20:56] <ikonia> keep it simple
[20:56] <goddard> running a vm means i can easily move it and dont have to perform the transfer twice
[20:56] <goddard> also can assign the vm a static ip
[20:56] <ikonia> you can assign a static ip to a desktop
[20:56] <goddard> also can use the server for other things
[20:57] <ikonia> you can use the desktop for other things
[20:57] <goddard> ikonia: not if the desktop is used for other things
[20:57] <ikonia> goddard: if the desktop is used for other things, it won't be able to host a vm
[20:57] <ikonia> I'm not seeing sane reasoning here
[20:57] <goddard> ikonia: it will if it is for a short period of time
[20:57] <ikonia> I'm seeing a desire for a transportable VM when there isn't really a need
[20:57] <ikonia> goddard: right, so just keep it simple, move the services to the desktop, re-insall your server and move them back
[20:58] <ikonia> you're adding complexity with a vm that's just not needed
[20:58] <goddard> it doesn't work like that and i would then have a bunch of extra garbage on the workstation
[20:58] <ikonia> so ?
[20:58] <ikonia> what are the services you're trying to migrate ?
[20:58] <goddard> im going to use a vm
[20:58] <ikonia> ok, use a vm then
[20:58] <goddard> i just dont know what to use
[20:59] <ikonia> then you sohld
[20:59] <ikonia> read up and work out what you want to use if you're blindly using a vm
[20:59] <goddard> haha
[20:59] <ikonia> I'm not laughing
[20:59] <goddard> did say you were
[20:59] <ikonia> no, but you said "ha ha" suggesting you found it funny
[21:00] <trippeh_> install libvirt-bin, qemu-system-x86 and virt-manager on the desktop. fairly easy to use.
[21:00] <goddard> i did
[21:00] <nacc> trippeh_: i think there are issues with 'live migration', but offline migration with libvirt should work ok
[21:00] <goddard> trippeh_: sure i know how to do all that, but then what issues would you encounter when trying to push that to the cloud server?
[21:00] <ikonia> goddard: "cloud server" ???
[21:00] <ikonia> what are you talking about
[21:01] <ikonia> cloud is just virtualization
[21:01] <goddard> yes it is
[21:01] <ikonia> so why would you have a problem then ?
[21:01] <goddard> why would i?
[21:01] <bekks> So which hypervisors are supported by the hoster of your "cloud server"?
[21:01] <ikonia> yes, why would you
[21:01] <ikonia> bekks: he hasn't gone one
[21:01] <ikonia> which is why I keep saying just do it "in situ"
[21:01] <goddard> bekks: i am the hoster
[21:01] <ikonia> wait until you do and then do it once there
[21:02] <bekks> goddard: Then which cloud are you talking about?
[21:02] <goddard> bekks: that is what I am asking
[21:02] <nacc> goddard: if *you* are the "cloud server", then what issues could you possibly hit?
[21:02] <ikonia> goddard: ????
[21:02] <nacc> goddard: it makes quite literally, no sense. You have 100% control over both environments, it sounds like
[21:02] <goddard> bekks: i know ubuntu has its own "cloudish" platform and proxmox and countless others
[21:02] <ikonia> goddard: you're not making sense, you're asking what issues you'd have going to your own personal cloud server....that doesn't exist
[21:02] <bekks> goddard: you are the hoster. not running any cloud. so what cloud are you talking about?
[21:03] <ikonia> goddard: if you want a really easy path - don't use a vm
[21:03] <ikonia> move the services, install your "cloud" server then just build a vm
[21:03] <ikonia> migrate your services to that new vm
[21:03] <ikonia> you'll find it a lot easier if you're not comfortable with the technology
[21:03] <goddard> ikonia: please stop suggesting that it won't work my friend
[21:03] <ikonia> goddard: why won't it work
[21:03] <ikonia> what's the actual problem
[21:04] <ikonia> (or potential problem)
[21:05] <goddard> i am going to to create a VM, which method and software to create the VM I don't know that is why I am asking.  In conjunction with my first statement I don't know what cloud server software to use to run on my server.
[21:05] <nacc> goddard: here is my read of your problem. You have a server and a workstation. You are going to reinstall the server so that it can run VMs. You want to 'save' the state of the server to a VM running on the workstation, and then migrate that VM to the server after it has been reisntalled. Is that correct?
[21:05] <ikonia> goddard: "cloud server" ???
[21:05] <ikonia> goddard: again, it's ust virtualization
[21:05] <bekks> goddard: Forget about "cloud software".
[21:06] <goddard> ikonia: yes i get it you are stuck on terms
[21:06] <bekks> goddard: You are just asking which hypervisor you should use.
[21:06] <ikonia> goddard: I'm not stuck on terms
[21:06] <goddard> people call it a cloud server and i realize it is a virtualization management system
[21:06] <ikonia> goddard: you are just saying words
[21:06] <bekks> And THAT question is just up to you needs, whishes desires.
[21:06] <bekks> *and
[21:06] <ikonia> goddard: right, so the managment doesn't matter
[21:06] <ikonia> goddard: what matters is the actual virtualization
[21:07] <ikonia> you don't seem to have a solid grasp on the virtual platform (not calling you for that) which is why I'm trying to suggest you a path that will allow you to do it easy while learn/understand how it works
[21:08] <goddard> So what cloud server software does ubuntu server recommend?
[21:08] <ikonia> none
[21:08] <ikonia> it's up to you
[21:08] <goddard> duh
[21:08] <ikonia> it's what you like/what you want to use
[21:08] <ikonia> it's very much down to technical requirements and personal preference
[21:08] <ikonia> and sometimes budget
[21:09] <ikonia> goddard: you've only got 1 host right ?
[21:09] <goddard> i only have 1 server that will stay up for ever
[21:09] <ikonia> goddard: right, so you don't really want "cloud" type setup, you just want a box to host VM's ?
[21:10] <goddard> yes
[21:10] <ikonia> right, so forget all that
[21:10] <ikonia> just build a box that is a VM host,
[21:10] <nacc> just use libvirt + kvm/qemu
[21:10] <ikonia> use the technology you like to host the VM's and keep it simple
[21:10] <ikonia> kvm, xen, virtualbox, whatever you like
[21:10] <ikonia> vmware
[21:10] <nacc> or if you have one you know better (virtualbox, vmware, etc.)
[21:10] <ikonia> anything,
[21:11] <ikonia> but forget clouds and cloud layouts, you're just going to create a problem
[21:11] <jrwren> goddard: uvt fronts virsh very nicely and makes it easy to start ubuntu virtual machines.
[21:11] <jrwren> goddard: but if that is all you need, you might consider using LXD instead of VM.
[21:12] <nacc> jrwren: good point
[21:13] <jrwren> goddard: what are you trying to do?
[21:15] <goddard> want to keep a web services, database, and email running and then install something like proxmox or similar software on the server to move that vm to the server
[21:16] <ikonia> promox has problems with the core config files on ubuntu based distros, bit like webmin used to
[21:16] <bekks> For the entire time of moving the vm, you will have a downtime.
[21:16] <ikonia> so be very careful
[21:16] <ikonia> and again - it's probably over the top for 1 vm host
[21:17] <nacc> proxmox seems like huge overkill for this
[21:17] <goddard> bekks: nah because i will set the other vm up with the second ip which will run the vm on a workstation while i am doing the install
[21:17] <ikonia> I don't get why it's being made into a complex mess
[21:17] <ikonia> move the services onto the desktop - no VM
[21:17] <ikonia> build a new host, build a vm
[21:17] <ikonia> migrate services to vm
[21:17] <ikonia> zero downtime
[21:17] <ikonia> zero risk, zero problem
[21:17] <bekks> goddard: So enlighten us how you are going to move an entire vm from one host to another without some HA functionality available.
[21:19] <goddard> ikonia: i really don't understand how you think that is possible based on what I told you.
[21:19] <goddard> guys
[21:19] <goddard> I have 1 server
[21:19] <ikonia> goddard: you've not told me what the problem is with doing it
[21:19] <goddard> 1 workstation
[21:19] <ikonia> goddard: what are the services that run on the server
[21:20] <ikonia> (the ones you want to migrate)
[21:20] <bekks> goddard: So move services to the workstation, setup your server, setup a vm, move your services to the vm.
[21:20] <goddard> It is going to run the LAMP stack amoung other things
[21:20] <bekks> I dont see the problem in doing so.
[21:20] <ikonia> goddard: ok - so thats no problem
[21:20] <ikonia> goddard: lamp stack will work great on a desktop, no problem there
[21:20] <ikonia> goddard: what else ?
[21:20] <goddard> bekks: that means moving things twice and what if you have to do it again?
[21:20] <goddard> it also disregards the current configuration
[21:21] <bekks> goddard: If you want to do that again, move the vm.
[21:21] <goddard> which may be different then the new configuration
[21:21] <goddard> or even different operating systems
[21:21] <ikonia> goddard: thats how you migrate
[21:21] <ikonia> you migtate from old to new
[21:21] <bekks> If you cant create a copy of a service config on anotherhost, maybe you should not migrate stuff.
[21:21] <goddard> ikonia: which is easy if you are moving to a similar configuration
[21:21] <ikonia> goddard: what OS does the desktop run
[21:21] <goddard> ikonia: the transfer will be done by hand
[21:22] <ikonia> goddard: so ?
[21:22] <ikonia> thats good
[21:22] <goddard> no easy button to transfer services
[21:22] <goddard> why do it twice?
[21:22] <ikonia> goddard: good
[21:22] <ikonia> becausae you don't seem to understand how to do it once
[21:22] <goddard> why replicate the environment and install things twice?
[21:22] <ikonia> so doing it safe and simple seems the best way
[21:22] <goddard> that is an huge waste of time
[21:22] <ikonia> not at all
[21:22] <ikonia> it's a simple and safe way
[21:22] <ikonia> goddard: what OS is the desktop running
[21:22] <goddard> and i also wouldn't have a vm server
[21:23] <ikonia> goddard: of course you would, you build it on the VM host
[21:23] <ikonia> and migrate to it knowing its up, it's routing, its working
[21:23] <goddard> this is headless
[21:23] <ikonia> headless is not a problem
[21:23] <ikonia> not quite sure why thats even being brought up
[21:23] <ikonia> goddard: what OS is the desktop running
[21:23] <goddard> ikonia: the workstation is ubuntu
[21:23] <ikonia> ubuntu what
[21:23] <goddard> the server is centos
[21:24] <ikonia> and centos what
[21:24] <goddard> 16.04
[21:24] <goddard> centos 7
[21:24] <ikonia> goddard: and your VM - will the VM be ubuntu or centos
[21:24] <bekks> And whats the problem with Centos 7, which is support for aeons, still? :D
[21:24] <goddard> the vm will be ubuntu
[21:24] <ikonia> goddard: ok - so that is the perfect way to do it
[21:24] <ikonia> goddard: migrate from centos to your workstation running 16.03
[21:24] <ikonia> then build your VM host, and your VM guest
[21:25] <ikonia> then migrate the services back knowing it works
[21:25] <ikonia> and knowing your vm is up, routed and running stable
[21:25] <goddard> and then migrate again? and do the work twice?
[21:25] <ikonia> because it's not
[21:25] <ikonia> one you've done it once, it's just copying the config giles
[21:25] <ikonia> file
[21:25] <goddard> it is already running stable now
[21:25] <ikonia> what's running stable now ?
[21:26] <goddard> i will know if it works by building the vm on the workstation and changing the host file
[21:26] <goddard> then just move the vm to the server
[21:26] <ikonia> that proves nothing
[21:26] <goddard> it proves it requires less work
[21:26] <ikonia> as that will all change when you move it to a difference host with different routing
[21:26] <ikonia> not it won't
[21:26] <ikonia> once you've done centos -> ubuntu migration on your desktop
[21:26]  * bekks wanders off
[21:27] <goddard> the routing is the same and just a static ip assignment
[21:27] <ikonia> it's very quick to do ubuntu -> ubuntu migration
[21:27] <ikonia> goddard: a static ip is not routing or virtual network routing
[21:27] <ikonia> thats just the presentation
[21:27] <goddard> so your idea is I should migrate from centos to ubuntu on the work station and then migrate again to the server
[21:27] <ikonia> goddard: that is the safest approach
[21:28] <ikonia> you can test the vm properly before migrating services to it
[21:28] <goddard> my idea is create a vm on the workstation and migrate from the server and then move 1 file to the server after setup
[21:28] <ikonia> and you can do all the migration work, while leacing your existing server running
[21:28] <ikonia> goddard: yeah, it's not as simple as moving a file
[21:28] <ikonia> your setups will not be transportable like that
[21:28] <goddard> isn't that why people use a vm?
[21:28] <ikonia> yes
[21:29] <ikonia> that is totally do-able and achieveable
[21:29] <ikonia> just not how you want to do it
[21:29] <ikonia> and with your understanding
[21:29] <ikonia> you'll probably understand it better once you build the vm host/guest
[21:29] <ikonia> and see how things like the network routing is done at a virtual and physical level
[21:30] <goddard> an easy problem to tackle with 2 ip addresses
[21:30] <bekks> Nope.
[21:30] <ikonia> no, it's not
[21:30] <ikonia> ip addresses are not routing
[21:30] <ikonia> they are just the presenstation
[21:30] <goddard> one ip can keep the server running on the workstation while the other gets setup
[21:30] <bekks> Nope.
[21:30] <ikonia> I suggest you just do it then
[21:30] <ikonia> as you'll not listen
[21:31] <bekks> After finishing the config in your vm, you need to shitut it down for moving it to your server.
[21:31] <bekks> That means "downtime".
[21:31] <ikonia> you'll also need to reconfigure the VM
[21:31] <bekks> You cannot leave the vm up and running while migrating it.
[21:31] <ikonia> as your workstations hardware and virtual network configuration and routing will be different
[21:31] <ikonia> which is means your VM may not come up
[21:31] <ikonia> or appear on the network - so it's down
[21:31] <ikonia> while you troubleshoot
[21:32] <ikonia> where as if you have a box up and running and you know it's good, you migrate the services knowing it's working
[21:32] <ikonia> and you can do it a lot easier on the fly
[21:32] <goddard> so potential down time is as long as the vm takes to copy
[21:33] <ikonia> no
[21:33] <bekks> Even longer.
[21:33] <ikonia> potentical down time is your vm copy time, your re-configuration time and troubleshooting any problems
[21:33] <goddard> ikonia: well not re-config time because you can just put the server up after you copy
[21:33] <ikonia> goddard: no you can't
[21:34] <ikonia> again - this is what I mean about your lack of understanding
[21:34] <goddard> it isn't a massivly used server
[21:34] <ikonia> so ?
[21:34] <ikonia> how does it's usage change anything ?
[21:34] <goddard> it might have small differences like a few emails being recieved
[21:34] <ikonia> no
[21:34] <ikonia> it's not that sort of difference
[21:34] <ikonia> this is pointless - you seem to be asking "how does this work" then saying "no, thats not how it works" when you are told
[21:34] <ikonia> what's the point of asking ?
[21:34] <ikonia> just get on with it
[21:34] <goddard> so reconfiguring a vm is impossible
[21:34] <goddard> that is what you are saying
[21:35] <ikonia> far from it
[21:35] <goddard> it is so difficult no one can do it
[21:35] <ikonia> nope
[21:35] <patdk-lap> it's simple to very annoying
[21:35] <patdk-lap> but it is never foolproof
[21:35] <ikonia> it depends on the hosts and guest configuration
[21:35] <goddard> this is a simple network
[21:35] <ikonia> no - it's not
[21:35] <goddard> this isn't a fortune 500 company
[21:35] <goddard> haha
[21:35] <ikonia> because you're on a physical network now,
[21:35] <ikonia> you'll need to do virtual networking with routing
[21:36] <ikonia> then routing to the physical network of the host
[21:36] <goddard> yes and that is why interfaces exist to help with that is it not?
[21:36] <ikonia> which will be different than your other host
[21:36] <ikonia> no, it's really not
[21:36] <ikonia> if you don't understand how it works - no interface will help
[21:36] <ikonia> building it will probably help you understand which is why I keep suggesting a specific approach
[21:37] <goddard> the server has a specific ip and then the vm has a specific ip and then you can control ports
[21:37] <goddard> i don't understand what you are talking about
[21:37] <ikonia> right - you don't understand
[21:37] <ikonia> that is the key thing
[21:37] <patdk-lap> ip's don't work without a proper network
[21:38] <goddard> that means nothing
[21:38] <patdk-lap> and since the network is virtual now, that is much more complex
[21:38] <ikonia> goddard: it means every thing
[21:38] <ikonia> just because they have the same ip on two different networks, you can't expect them to work the same
[21:38] <patdk-lap> hell, even though I use esxi and pay vmware for licensing
[21:38] <patdk-lap> and they make it *very simple*
[21:39] <patdk-lap> I still have lots of odd issues, and driver problems
[21:39] <patdk-lap> that only come into play when attempting to do virtual networks that touch physcial networks
[21:40] <goddard> ive setup tons of vms and exposed them to the internet without problem
[21:40] <goddard> i dont get what you are going on about
[21:40] <ikonia> I don't understand how you can "setup tons of vms" and not understand the networking
[21:41] <ikonia> and if you've done tons of vm's how are you asking us "what software to use" and "how to do this"
[21:41] <goddard> ikonia: thats becuase the software i use handles it i just give it an ip
[21:41] <ikonia> goddard: so you've not done anything then
[21:41] <goddard> i dont have to know how a virtual machine and a physical machine route traffic
[21:41] <ikonia> you've just used a vm
[21:41] <goddard> that is the softwares job
[21:41] <ikonia> you do now
[21:41] <ikonia> as you want to host it
[21:41] <ikonia> using a vm is different than hosting a vm host
[21:41] <patdk-lap> someone had to make that software
[21:42] <patdk-lap> and have it conform to some kind of network design
[21:42] <ikonia> goddard: it seems you don't really want to listen to experience - you know it all already, it's easy
[21:42] <ikonia> so just get on and do it
[21:42] <patdk-lap> or conform the physical network to it's design
[21:42] <patdk-lap> either way you need to know how it works
[21:42] <ikonia> there seems little point in any more discussion
[21:42] <ikonia> just get on with it
[21:43] <goddard> ikonia: im trying to understand but how can i know what I don't know
[21:44] <ikonia> goddard: then start listening
[21:44] <ikonia> rather than telling us how it works
[21:44] <ikonia> listen to how it works and try to understand
[21:44] <goddard> you aren't giving me examples or solutions you are just giving me your alternatives
[21:44] <ikonia> my alternatives are examples of solutions
[21:44] <patdk-lap> ah, you want a tutorial
[21:44] <ikonia> you've got it in your head how it works
[21:44] <goddard> ikonia: i know and i get that
[21:45] <patdk-lap> but a tutorial is the same, it conforms things to that users needs
[21:45] <ikonia> goddard: is there a genuine reason you don't want to do what I've suggested
[21:45] <ikonia> as I think if you do it how I've suggeted you'll hit some problems, but learn a LOT more
[21:45] <ikonia> if you do it how you want to do it with the level of understanding you have, you will fail
[21:49] <terje> anyone know of a tutorial for installing 16.04 + maas + juju + openstack?
[21:49] <terje> or should I document my adventure.. :)
[21:50] <ikonia> terje: the software install is easy, you'll need to plan it out as a layout before looking at config options
[21:50] <ikonia> terje: certainly sounds like something that would be worth documenting depending on your layout
[21:50] <terje> sure, I have a pretty standard setup I'd imagine.
[21:50] <goddard_> https://youtu.be/OCMWhAb69ec?t=99
[21:51] <ikonia> goddard: why are you showing us that ?
[21:51] <terje> 8 physicals with 3 nic's, 2 disks
[21:51] <terje> I wish to run ceph for cinder volumes, etc.
[21:51] <terje> I guess I'll see how it goes.
[21:51] <goddard_> ikonia: it is a network interface editor screen
[21:51] <ikonia> terje: get it documented !
[21:51] <ikonia> goddard_: so ?
[21:51] <ikonia> goddard_: what does that have to do with anything ?
[21:52] <goddard_> ikonia: so what complicates would i run into after transfering the vm and how can it be avoided
[21:52] <ikonia> goddard_: everything I've just said
[21:52] <ikonia> goddard_: if you're that confident it's that simple/easy - just do it
[21:52] <ikonia> get on with doing it
[21:53] <goddard_> ikonia: you just told me it will have a different interface
[21:53] <ikonia> goddard_: what ?
[21:53] <ikonia> goddard_: I said nothing about different interfaces
[21:53] <ikonia> I said having an interface won't help if you don't understand how the networking works
[21:55] <goddard_> nothing works if you don't understand it but that doesn't help
[21:55] <ikonia> what ?
[21:55] <goddard_> dont know how my os does absolutely everything it does but it doesn't prevent me using it
[21:55] <ikonia> goddard_: why are you not doing this ?
[21:55] <6A4AA5LGC> ikonia: I will.. just so I can repeat. :)
[21:55] <ikonia> then get on with doing it
[22:18] <JaguarDown> Any danger in running apt-get autoremove if aptitude told me to because a bunch of packages are "no longer required?"
[22:20] <ikonia> JaguarDown: nope
[22:20] <JaguarDown> Thanks
[22:21] <JaguarDown> While I'm on the subject...
[22:22] <JaguarDown> I'm still running 14.04, I suppose I should do a backup etc, but any danger of breaking things by upgrading to 16.04?
[22:22] <JaguarDown> I'm running pretty standard things like apache, an ircd, email stuff, etc.
[22:32] <nacc> JaguarDown: i'd wait til 16.04.1 before upgrading
[22:32] <nacc> !ltsupgrade
[22:35] <JaguarDown> Okay, I didn't know that, thanks.
[22:39] <nacc> JaguarDown: np
[23:35] <Seveas> JaguarDown: I think you'll be getting the apache 2.2 to 2.4 upgrade, which has some backwards incompatibilities