[00:05] <espacious> if i only simulate the drive failure with mdadm --fail on reboot it will need to rebuild?
[03:44] <jtmoney> wow, i just installed 8.10... THANK YOU SO MUCH! the fakeraid support is amazing... so seamless
[03:44] <jtmoney> thank you
[03:50] <genii> If I want to be alerted by SMS on ups remianing time or such and already have a working freepbx for instance, what approach should I take?
[03:52] <genii> Probably hack apcutils or so I suppose
[03:53] <genii> apcupsd  rather
[03:53] <jtmoney> maybe i spoke too soon... seems to be stuck at 33% when trying to format my raid-1 set up :(
[03:54] <jmarsden> If it already logs messages via syslog, you could probably use swatch or some similar logwatcher to email you (to your cellphone) when relevant lines appear in the appropriate log file.  Should avoid any need to hack anything?
[03:54] <genii> jmarsden: Thing is I pay for emails to my phone but texts are free
[03:55] <jmarsden> OK.  Strange policy that... so do you have a way to generate SMS msgs on your server already that works with your cell provider?
[03:57] <genii> jmarsden: Not sure. The asterisk backend can do for instance bridge to POTS from SIP or so
[03:57] <jmarsden> OK.  So as long as you ahve some command line tool to send SMSes, you can configure either the UPS software (nut or apcupsd etc) ot logwatch to run it when soemthing happens that you care about.
[03:58] <jmarsden> I know nut can be configured to run arbitrary notifier programs, not so sure about apcupsd.
[03:58] <genii> I think it can, yes
[03:59] <jmarsden> Then you just need to find that command line SMS-send tool and you're golden.
[03:59] <genii> Maybe I'll just have it phone me physically and play back some festvox thing saying "so many minutes of power left" or so...
[03:59] <jmarsden> :-)
[04:00] <genii> jmarsden: Thanks for the input
[04:00] <jmarsden> No problem.
[04:36] <jtmoney> hey guys, i need some help... i'm trying to use fakeraid with 8.10 server amd64... however, when writing the partition configuration to disk, it always gets stuck at 33%... this is what i get in the console
[04:36] <jtmoney> partman: warning: 176 blocks unused.
[04:36] <jtmoney> partman:
[04:36] <jtmoney> it seems like it's returning an error, it's just not displaying it
[04:38] <jmarsden> jtmoney: Is there really any benefit on fast 64-bit hardware to using device-specific fakeraid (why not just use software RAID)?
[04:39] <jtmoney> i guess... i'm only interested in RAID-1 anyways
[04:39] <jmarsden> https://help.ubuntu.com/8.10/serverguide/C/advanced-installation.html even claims software raid can be better than some fakeraid implementations
[04:40] <jmarsden> I'd switch to software raid and see how well that works.
[04:42] <jtmoney> i don't think i have an option :)
[04:42] <jtmoney> hmm
[04:42] <jtmoney> well, maybe i should use 8.04 LTS now instead
[04:42] <jmarsden> Well, you could look for bugs on LP related to your specific fakeraid chip, etc...
[04:43] <jmarsden> 8.04 LTS doesn't do boot degraded stuff with software RAID though... why go back to an older version, unless you really do need the LTS aspect?
[04:43] <jtmoney> good point
[04:46] <jtmoney> actually, i hear the hard drives
[04:46] <jtmoney> maybe it just takes a while to set up 2 x 1 TB RAID-1
[04:46] <jtmoney> that leads me to another question... and this is not clarified in the fakeraid howto
[04:46] <jtmoney> should i configure the raid within the bios?
[04:47] <jtmoney> or don't configure the raid in the bios and let ubuntu handle it
[04:47] <jmarsden> I'm not sure, I last tried fakeraid in Linux at least 5 years ago... was unhappy, switched to software RAID and stayed that way, except for "serious" servers with hardware SCSI RAID controllers!
[04:48] <jmarsden> I suspect the BIOS won't matter, Ubuntu will set it up; but I'm not at all sure of that.
[04:48] <jtmoney> hmm, it does seem better to do software raid
[06:41] <jtmoney> what happens if i have a software RAID-1 set up and i were to take one of the hard drives and try to mount it in another machine, would i be able to see all my data?
[06:45] <[Solars]> no
[06:47] <jtmoney> but if i were to implement them using fakeraid RAID-1, the drives would act independently, right?
[06:47] <jtmoney> i.e., there's no RAID-specific data on the drives in RAID-1
[06:55] <[Solars]> if you using a software raid, the software does the raiding scheme, if you using hardware raid the hardware does it... depending on the raid type, data are all drives
[06:55] <jtmoney> okay, thanks solars
[08:08] <kraut> moin
[08:13] <Jeeves_> morning
[08:14] <Jeeves_> kraut: you're Karl right?
[08:15] <kraut> i'm kraut, ok? ;)
[08:16] <Jeeves_> kraut: Sorry, I'm confused
[08:16] <kraut> hehe, no problem
[08:16] <Jeeves_> I'm looking for Karl Goetz
[08:17] <Jeeves_> He wrote something very curious and I was wondering if he's serious or not
[08:24] <LoveGuru> there is one log file in log folder. i want to copy all text whatever that file have it. so i can paste it on pastebin how can i do that?
[08:32] <ropetin> LoveGuru: pastebinit maybe?
[08:35] <_ruben> Jeeves_: that'd be kgoetz or, crap, his other nick slipped my mind
[08:35] <_ruben> Kamping_Kaiser == kgoetz
[08:55] <Jeeves_> _ruben: Ah yes
[09:21] <_ruben> wow .. bind 9.5 statistics channel feature sure is sweet
[09:25] <_ruben> spits out xml output over http with a bucketload of info
[11:18] <Kamping_Kaiser> Jeeves_, you were after me?
[12:46] <ahasenack> Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/h/hplip/hpijs_2.7.7+2.7.7.dfsg.1-0ubuntu5.1_i386.deb  Size mismatch (gutsy hpijs update), is this known? Just a bad mirror?
[13:18] <zul> Koon: hardy isnt affected by the nagios-plugins bug is it?
[13:18] <Koon> zul: no, the overflow doesn't trigger anything
[13:18] <zul> Koon: cool just checking
[13:19] <Koon> zul: it's still wrong, but invisible
[13:19] <zul> Koon: heh qualitiy
[13:33] <ScottK> zul: No.  It's kwality.
[14:51] <ladfnet> I'm having a problem with my network configuration. I'm running two vlans of eth0, and they're configured in /etc/network/interfaces. It boots fine, and both vlans work, but if I do a /etc/init.d/networking restart then the network shuts down. It's a remote server, and I'm configuring over ssh, and I'm running automatic restarts of the server through a cronjob. If I remove the second vlan(not the internet connection) then it works fine, 
[14:51] <ladfnet> I tried to pipe error to one file, and output to another, but no errors are reported from the networking restart
[14:51] <ladfnet> any ideas?
[16:01] <zul> Koon: ping
[16:01] <Koon> zul: pong
[16:02] <zul> I have backported the dfs patch to the intrepid kernel, ill push it today to the kernel guys
[16:02] <Koon> zul: did you test that it fixes it ?
[16:03] <zul> Koon: no its from linus' tree so it should be good
[16:13] <mathiaz> zul: Koon: AFAICT there are two bugs related to cifs
[16:13] <mathiaz> bug 286828
[16:14] <Koon> mathiaz: only two ?
[16:14] <mathiaz> Koon: hm - ok... Two that I know of wrt to interpid upgrades :)
[16:15] <zul> mathiaz: that one is a kernel "bug" the other is a libsmbclient one that we already did the SRU for
[16:15] <mathiaz> Koon: although one of them is related to samba.
[16:15] <Koon> the other would be... bug 282298 ?
[16:15] <mathiaz> zul: right - the one that truncates the last caracated?
[16:15] <zul> mathiaz: correct
[16:15] <Koon> that one should be fixed now
[16:16] <Koon> in jaunty and intrepid-proposed
[16:16] <mathiaz> soren: kirkland and I worked on iscsi yesterday
[16:17] <soren> mathiaz: Do tell.
[16:17] <mathiaz> soren: and we came up with a if-up.d scripts that works
[16:17] <kirkland> soren: i think we made some nice progress
[16:17] <soren> mathiaz: An if-up.d script for what?
[16:17] <mathiaz> soren: basically symlinking the init script in /etc/network/if-up.d/
[16:17] <mathiaz> soren: and adding support of  if-up.d calls to the init script.
[16:18] <soren> mathiaz: Ok...
[16:18] <kirkland> soren: to ensure that the iscsi daemon starts when the networking comes up
[16:18] <mathiaz> soren: we've also tried to start open-iscsi at S25 and that would not work
[16:18] <soren> mathiaz: Why?
[16:18] <mathiaz> soren: the interfaces are not up by then
[16:18] <soren> mathiaz: Physical interfaces?
[16:18] <kirkland> soren: it's not deterministic that the interface will be up by then
[16:18] <mathiaz> soren: at least in our vm system.
[16:19] <mathiaz> soren: physical in the sense that we've tested in kvm
[16:19] <soren> mathiaz: I mean: Not bridges or bonded interfaces?
[16:19] <soren> That sounds like a bug.
[16:19] <mathiaz> soren: starting open-iscsi in if-up.d makes *sure* that the network interface is running
[16:19] <soren> *a* network interface.
[16:19] <mathiaz> soren: I haven't tested bridges and bonded interfaces yet
[16:20] <mathiaz> soren: true - however you can call iscsiadm with an interface option
[16:20] <soren> What does that do?
[16:20] <mathiaz> soren: which *should* select targets that are only accessible via the interface
[16:20] <soren> interesting.
[16:21] <mathiaz> soren: since we have the name of the interface in IFACE when called in if-up.d we should be able to tell iscsiadm to only login targets that are setup to use the interface that has been created.
[16:22] <mathiaz> soren: the other reason for using if-up.d is that _netdev mounts in fstab are mounted by if-up.d/mountnfs
[16:22] <mathiaz> soren: so if we'd run open-iscsi at S45 (or S25) _netdev mounts in fstab would not be mounted
[16:23] <soren> ARGH!
[16:23] <soren> bug 44194
[16:23] <soren> I still think _netdev is a horrible, horrible idea.
[16:23] <mathiaz> soren: this is why debian has call to mount -a -O _netdev in their open-iscsi init script
[16:24] <mathiaz> soren: right - so I thought about another option here
[16:24] <mathiaz> soren: is it possible to teach udev to check fstab UUID when a device is created?
[16:24] <soren> What do you mean?
[16:24] <mathiaz> soren: because when the initiator logs into a target, devices are created
[16:24] <soren> Right.
[16:25] <mathiaz> soren: once you've logged into a target, you'll have a device in /dev/disk/by-uuid/
[16:25] <soren> Yes.
[16:25] <mathiaz> soren: that will be the UUID of the fs
[16:25] <soren> YEs.
[16:25] <mathiaz> soren: this UUID is also used in fstab
[16:25] <soren> Yes.
[16:25] <soren> :)
[16:26] <mathiaz> soren: so - could udev scan fstab and do the mount?
[16:26]  * soren has a hunch that there's a reason why not to do that, but can't remember why..
[16:27] <mathiaz> soren: I'll ask KeyBuk in #ubuntu-devel
[16:27] <soren> Maybe it's an ordering thing.
[16:28] <soren> You don't know for sure that mounting them in the order in which they appear will give the results you want.
[16:29] <mathiaz> soren: right - so you could end up in situation where /srv/disk1 is a local disk
[16:29] <soren> Hm?
[16:29] <mathiaz> soren: and /srv/disk1/iscsi1 is remote isci disk
[16:29] <soren> Oh.
[16:29] <mathiaz> soren: but the iscsi target would come up before the local disk is mounted
[16:29] <soren> Oh, yes, if you only do it to iscsi targets.
[16:37] <soren> mathiaz, kirkland: Honestly, I don't remember all the details.
[16:37] <soren> I just remember spending lots and lots of time on this, and came to the conclusion that S25 was the right place to start it.
[16:38] <soren> Now, siretart broke that, clearly, but that's bug that needs fixing.
[16:39] <kirkland> soren: hmm, we had no success with it at S25...  the ifup script seems to work far better in all use cases we've tested so far
[16:40] <soren> kirkland: Exactly..
[16:40] <soren> kirkland: Like I just said: siretart clearly broke it.
[16:40] <soren> kirkland: Because *no* interfaces will ever be up at that point.
[16:44] <Koon> mathiaz: beware of the shutdown order too -- we already have lots of bugs about network file systems being unmounted after network is gone.
[16:45] <kirkland> Koon: we actually fixed that too, for iscsi
[16:45] <kirkland> Koon: it was being shutdown in the wrong place, pre-merge
[16:46] <Koon> kirkland: cool, would the fix also be applicable to other network mounts ?
[16:46] <kirkland> Koon: now, it's taken down by the umountnfs scripts
[16:46] <kirkland> Koon: assuming that the fstab entry is tagged with _netdev
[16:46] <kirkland> soren: can you explain why you hate on _netdev so much?
[16:47] <soren> Because I think it's the way it would have been done in the 70's.
[16:47] <soren> Or in Debian.
[16:48] <soren> ...which -- in this respect -- turns out to be quite similar.
[16:48] <soren> Don't get me wrong. I love Debian with a passion..
[16:48] <soren> ..but when it comes to the whole boot process and all that? Sheesh.. Get with the programme!
[16:50] <soren> I think it's a crude, crude hack to work around the real issue:
[16:50] <soren> That we're too stupid to get the iscsi devices to pop up in time for the whole mounting thing.
[16:50] <soren> I think that's:
[16:50] <soren> a) A much more interesting problem to solve
[16:50] <soren> and
[16:51] <soren> b) what will be of most benefit to the users in the end.
[16:51] <soren> and me.
[16:51] <soren> :)
[16:51] <soren> kirkland: ^
[16:59] <hansin> I was just thinking about the announcement that Canonical/Ubuntu will support the ARMv7 processors in the 9.04 release.  Will the server edition be included with this?  I understand that the server edition comes for the same repos, but I guess I am wondering if the unique parts (like kernel) will be compiled for ARMv7?  Thanks.
[17:04] <soren> hansin: The server flavour on PC hardware exists because we want a different configuration than on the desktop. If the same makes sense on ARM, we might very well have a separate flavour there as well.
[17:06] <W8TAH> can someone please point me to a good instructions on installing and using vmware-server on ubuntu server?
[17:22] <andol> W8TAH: https://help.ubuntu.com/community/VMware/Server
[17:28] <W8TAH> andol: thank you
[17:43] <JDStone> are there any limitations with the 64bit version of Ubuntu server?
[17:43] <JDStone> that I should know about?
[17:43] <mathiaz> EtienneG: do you have your iscsi testing environment ready?
[17:44] <EtienneG> mathiaz, yes, I guess
[17:44] <mathiaz> EtienneG: do you have a setup with more than one interface?
[17:44] <mathiaz> EtienneG: bonding? bridged?
[17:44] <EtienneG> mathiaz, if by "environment", you mean a vm running the target and a vm running the initiator
[17:44] <EtienneG> mathiaz, yes, the iniattor is configured with bonded Ethernet
[17:45] <mathiaz> EtienneG: great - I'll get a link to a new open-iscsi package
[17:45] <mathiaz> EtienneG: if you could test it in your environment that would be helpful
[17:45] <EtienneG> JDStone, none, except possibly that some third-party software and driver may be 32 bits only
[17:46] <EtienneG> but hopefully, these would not be relevant to you
[17:46] <EtienneG> mathiaz, 'k, send me the link, I get that done this afternoon ASAP
[17:46] <JDStone> yeah, that's what I'm thinking
[17:46] <JDStone> thanks EtienneG that helped
[17:46] <JDStone> that's all I needed to know
[17:47] <EtienneG> JDStone, that's really just IME, you may want to ask a second opinion
[17:48] <EtienneG> JDStone, one annoying bug I had was running hardy 64 bits on VMWare ESX 3.5
[17:48] <EtienneG> but that was specific to that particular setup
[18:07] <Faust-C> what is a good app to connect to ftps/sftp/webdavs
[18:07] <Faust-C> nautilus errors out
[18:08] <Faust-C> and lftp wont put a folder
[18:13] <kopo> Hi!
[18:14] <kopo> Is there any way to configure Alt+F2-F6 buttons in shell?
[18:14] <Deeps> configure to do what?
[18:14] <kopo> Normally you can switch between virtual consoles..
[18:14] <Deeps> yep, thats default behaviour
[18:14] <kopo> ..but I want to run different programs..
[18:14] <Deeps> so switch to the different console, login and run the program?
[18:15] <Faust-C> screen?
[18:15] <kopo> like F2 for irssi ;) F3 for top
[18:15] <Faust-C> kopa, screen tabs
[18:15] <Faust-C> sec
[18:15] <Deeps> screen tabs would be a better idea, yeah, but no reason why you cant do what you want with multiple consoles
[18:15] <Deeps> just means logging in first on each console
[18:15] <hansin> soren: Thanks.  The reason I ask (about ARMv7 server edition) is that a few months ago I saw a talk given by the guy who first cracked the
[18:16] <Faust-C> kopa, http://www.bsdguides.org/guides/freebsd/misc/screenrc
[18:16] <hansin> woops.  Linksys NSL
[18:16]  * Faust-C wrote that
[18:16] <Deeps> Faust-C: sftp (cli util) will do recursive dirs i believe
[18:16] <Faust-C> Deeps, ah sweet, i thought so
[18:16] <kopo> hmm.. what do you think? screen tabs or multiple consoles?
[18:16] <hansin> NSLU2.  It can run ARM debian.  But I could imagine some really cool ARMv7 based devices for home servers (or even lightweight business servers).
[18:17] <Deeps> kopo: whichever makes you happier
[18:17] <Deeps> kopo: i'd use screen personally as it meanas you can ssh in from remote and reattach to the same sessions
[18:18] <Faust-C> kopa, multiple considers means more reasources
[18:18]  * Faust-C does the screen dance
[18:18] <Deeps> your guide is very inconsistent btw faust
[18:19] <Deeps> well, 'very' is going a bit far
[18:19] <Deeps> looking at your screenrc, lines 3+4 dont seem to relate to the comment on the line above it
[18:19] <Faust-C> Deeps, its dated
[18:19] <Faust-C> thats a old one
[18:19] <kopo> thanks!
[18:20] <Faust-C> i dont have my newest one up yet
[18:20]  * Faust-C will once i have site the way i like it
[18:20] <Faust-C> Deeps, and btw that is right
[18:20] <Faust-C> oh crap no its not
[18:20] <Faust-C> wait no its right
[18:21] <Faust-C> cause F1 doesnt = F1
[18:37] <paul68>  I tried through this howto to make my iptables to run when I boot up my system however I don't get any response that its or its not working can someone help me out with this  https://help.ubuntu.com/community/IptablesHowTo#Configuration%20on%20startup
[19:16] <danielm_mc> ﻿anyone know how to disable the f1 key from displaying the help menu in a terminal?
[19:17] <greenfly> danielm_mc: you'd have to go to the gnome keybinding settings probably
[19:17] <danielm_mc> yaah, i actually just figured it out
[19:18] <danielm_mc> gotta go to key shortcuts
[19:18] <danielm_mc> man #ubuntu is about 0 help about 100% of the time unless you're stuck trying to install a mouse
[19:19] <greenfly> heh
[19:22] <danielm_mc> yeh sucks, i hate to bother this crowd with dumb questions like that, but whatev
[19:25] <bluedragonpiper> I am receiving a failed to fetch error (404) in aptitude and not sure how to resolve it when trying to get this file: http://security.ubuntu.com/ubuntu/pool/main/libx/libxml2/libxml2_2.6.31.dfsg-2ubuntu1.2_i386.deb
[19:25] <bluedragonpiper> I have checked the files at that location and found similar file: libxml2_2.6.31.dfsg-2ubuntu1.3_i386.deb
[19:27] <greenfly> try to do an aptitude update first
[19:30] <bluedragonpiper> greenfly: Thanks a million, I read through the apt-get and apt-cache manpages several times assuming aptitude was just a frontend... *smacks forehead
[19:33] <greenfly> np
[20:30] <soren> mathiaz, kirkland: Do you need anything else from me on the topic of iscsi tonight?
[20:34] <kirkland> soren: hmm
[20:34] <kirkland> soren: well, not really
[20:34] <kirkland> soren: i'm not sure the approaches you're asking for are doable within a reasonable timeframe at this point
[20:34] <soren> Define "reasonable timeframe".
[20:35] <soren> Noone's demanding that this work by alpha 1 :)
[20:35] <kirkland> soren: well, we've got a package that works ***far*** better than any open-iscsi package that we've ever had in Ubuntu before
[20:36] <kirkland> soren: we can upload that now, in early jaunty, and incrementally improve the package through the development cycle
[20:36] <mathiaz> EtienneG: could test the open-iscsi package from http://people.ubuntu.com/~mathiaz/packages/?
[20:36] <mathiaz> soren: you may wanna have a look at these ^^ too
[20:37] <mathiaz> soren: the changelog is not up-to-date though,
[20:37] <kirkland> soren: alternatively, multiple of us can spend several more days/weeks rearchitecting it before we have something that even works
[20:38] <soren> Look... You asked my advice.
[20:38] <soren> No need to get all hands up in the air about it.
[20:39] <soren> And I seriously doubt it would take that much time.
[20:39] <soren> I'm still quite sure starting iscsi before mountall is the right thing to do.
[20:40] <soren> What we need to do is to make sure as many cases of networking are functional at that point.
[20:40] <soren> Most notably bonding, but also bridging.
[20:41] <soren> It's very much in the spirit of all the other stuff we've changed in the boot process.
[20:42] <soren> Why did you drop "Exit without error if /sys is not available. Otherwise, it's not possible to use this package as a build-dependency.
[20:42] <soren> "
[20:42] <soren> ?
[20:42] <kirkland> soren: i couldn't agree more with your point: "What we need to do is to make sure as many cases of networking are functional at that point."
[20:42] <soren> In fact, apart from the homepage thing, why did you drop those the two other changes?
[20:43] <soren> (I've only looked at the changelog so far)
 soren: the changelog is not up-to-date though,
[20:43] <soren> I saw that. Did those things not get dropped anyway?
[20:44] <mathiaz> soren: IIRC they were merged in debian
[20:44] <soren> If "remove open-iscsi init script on upgrades before hardy" does what I think I remember it does, I find it somewhat hard to believe that it's in Debian now.. :)
[20:44] <mathiaz> soren: that is something that we can dropped
[20:45] <mathiaz> soren: the changelog is not up-to-date. But at least that specific code (update-rc.d -f remove open-iscsi) is not useful now
[20:45] <soren> Why?
[20:45] <soren> I'm genuinely curious.
[20:45] <mathiaz> soren: since it would be run if we're upgrading from lt hardy version
[20:46] <soren> Good point.
[20:46] <soren> Err...
[20:46]  * soren goes to check something.
[20:46] <mathiaz> soren: http://paste.ubuntu.com/74941/
[20:47] <mathiaz> soren: that's the full code in the postinst
[20:47] <soren> mathiaz: Are you moving the K??open-iscsi script?
[20:48] <kirkland> soren: we needed to come after sendsigs
[20:48] <mathiaz> soren: yop - to after sendsig
[20:48] <mathiaz> soren: and also after umountnfs
[20:48] <mathiaz> soren: which takes care of umounting netdev filesystems
[20:49] <soren> "If  any  files  /etc/rcrunlevel.d/[SK]??name  already exist then update-rc.d does nothing."
[20:49] <soren> From update-rc.d man page.
[20:49] <soren> So if someone already has the package installed, they won't get moved unless you remove the existing ones.
[20:49] <kirkland> soren: so we'll need some postinst special code?
[20:49] <soren> ...which is why that line of code was tehre.
[20:49] <kirkland> soren: ah
[20:50] <mathiaz> soren: oh ok.
[20:50] <kirkland> a comment of documentation in there would be nice :-)
[20:50] <mathiaz> soren: so we need to update the package version
[20:50]  * soren seems to remember saying something about removing code you don't know why is there to begin with... :)
[20:51] <kirkland> okay okay :-)  we'll add a line explaining what the point of that block is
[20:51] <soren> What you should do (and what I really should have done, but clearly I was being lazy) is to check if the offending symlink is there and then rename it.
[20:51] <soren> What I did was effectively throwing away the sysadmin's changes...
[20:51] <kirkland> fair enough
[20:52] <kirkland> that way, we'll only touch a symlink that we know the previous package put there
[20:52] <soren> YEs.
[20:52] <kirkland> and it'll be self-documenting, clearer what the end goal is
[20:52] <soren> And just keep your fingers crossed that people didn't move those symlinks in an attempt to fix various things.
[20:52] <soren> ...which, now that I think about it, might have been why I just forced it.
 a comment of documentation in there would be nice :-)
[20:53] <espacious> hi soren i managed to solve the problem with my raid. the trick was my bios is old and i had to reset it and set it up again (hdd detect issues)
[20:53] <soren> espacious: What did that matter?
[20:53] <soren> kirkland: 20:50:37  * soren seems to remember saying something about removing code you don't know why is there to begin with... :)
[20:53] <espacious> soren the disk was not detected properls or the ata cable was bad plugged.i dont know.
[20:54] <espacious> fact is now is ok.
[20:54] <soren> espacious: I'm sorry, but I don't buy that explanation :)
[20:54] <soren> espacious: I suspect something else was really up that now happened to be fixed when you went through it for the third time.
[20:54] <soren> ...or something.
[20:54] <kirkland> soren: agreed :-)
[20:54] <espacious> soren but! i messed sth up again since i made xfs on the md3 array but it wont mount
[20:55] <soren> kirkland: This messing about with those symlinks is a good reason why it might be a good idea to not upload a half solution now and changing it later.
[20:55] <espacious> soren no the ata cable was the trouble it was wrong connected i got ATAPI incompatible message at boot but i didnt saw it. now i repaired that and rabuild went ok
[20:56] <soren> kirkland, mathiaz: is there anything in particular that makes you want to push this sooner rather than later?
[20:56] <soren> espacious: Oh, I see.
[20:56] <soren> espacious: Well, that's good.
[20:56] <mathiaz> soren: why do you want later?
[20:56] <kirkland> soren: to establish something to test off of, early in the dev cycle
[20:56] <soren> mathiaz: 20:55:39 < soren> kirkland: This messing about with those symlinks is a good reason why it might be a good idea to not upload  a half solution now and changing it later.
[20:57] <soren> It's an extra upgrade case you need to handle in the maintainer scripts.
[20:57] <espacious> soren so can u throw an eye at my logs to see where is the problem now.
[20:57] <soren> espacious: I can try.
[20:57] <espacious> soren u are veri kind.
[20:57] <espacious> very*
[20:57] <soren> mathiaz, kirkland: Especially if we all agree that it's not the rigth approach... but I get the feeling this might not be the case after all.
[20:58] <mathiaz> soren: so if we'd go for later, what should be done to get a correct upload?
[20:58] <espacious> how's the /smome/some/asds.log| pastebin command ?
[20:58] <kirkland> soren: mostly, i think, because there's going to be some work required in the installer, which will need to be done earlier in the Jaunty cycle than we started looking at this in Intrepid
[20:58] <soren> mathiaz, kirkland: Maybe you can tell me? I'd like to hear your version.
[20:58] <soren> espacious: No idea. I'm a copy/paste monkey myself.
[20:59] <kirkland> soren: a merge of upstream, plus (at least mostly) better working code is a pre-req to going much further
[20:59] <espacious> sore ok. will find out not a problem i will post u links in 5 min.
[20:59] <soren> kirkland: I'm sort of looking for a definition of "better working code".
[20:59] <kirkland> soren: okay, we've split the whole iscsi problem into 3 parts ....
[20:59] <soren> kirkland: What are the success criteria, and what's the strategy to get us there?
[21:00] <mathiaz> soren: the *current* state in interpid/jaunty is that open-iscsi doesn't work
[21:00] <soren> kirkland: Ok, go on.
[21:00] <kirkland> soren: 1) root on iscsi, which is a different beast, we're putting that off until later
[21:00] <soren> mathiaz: I know.
[21:00] <mathiaz> soren: there is a mismatch between the kernel version and the userspace
[21:00] <soren> mathiaz: Right.
[21:00] <mathiaz> soren: so from that point of view, it's better code as it works now
[21:00] <kirkland> soren: 2) iscsi in the installer, which depends on a working #3, which is ....
[21:00] <kirkland> soren: 3) other, non-root iscsi filesystems
[21:01] <kirkland> soren: we're focusing on 3 at the moment
[21:01] <soren> Ok. So how about just uploading a new set of tools and deal with the integration details later?
[21:01] <kirkland> soren: now, under that, we have to consider several different forms of networking
[21:01] <soren> ...thus limiting the amount of upgrade cases to worry about.
[21:01] <kirkland> soren: but we've determine that we need to go after the lion's share (90%?) of common networking setups
[21:01] <soren> kirkland: Yes. Which really is an issue separate from iscsi, but we happen to depend on it working properly.
[21:01] <kirkland> soren: use the default interface, bonded, etc.
[21:02] <kirkland> soren: and put aside a few of the more esoteric ones, for now
[21:02] <soren> kirkland: I really don't give a hoot about wpasupplicant here, for instance.
[21:02] <kirkland> soren: so success criteria ....
[21:02] <soren> If it happens to work, fine. Bonding is really important, and bridging is rather important.
[21:02] <soren> IMO, that is.
[21:02] <kirkland> soren: agreed on that
[21:02] <kirkland> soren: for (3), having a Jaunty install, with open-iscsi installed
[21:02] <kirkland> soren: that can run iscsi_discovery
[21:03] <kirkland> soren: to find, and attach to a target
[21:03] <kirkland> soren: get its /etc/iscsi configuration written properly
[21:03] <kirkland> soren: get a workable /etc/fstab entry
[21:03] <kirkland> soren: and reboot ad nauseum, with the filesystem automounting/auto-umounting cleanly, successfully, reliably
[21:04] <soren> Sounds good.
[21:04] <kirkland> soren: and testing that out of some finite list of networking setups
[21:04] <kirkland> soren: default ethernet, bonded ethernet, bridged seems like a reasonable starting point
[21:04] <kirkland> soren: vnet's maybe coming later
[21:04] <soren> vnet's?
[21:04] <kirkland> soren: and all of the other crazy networking setups we'll handle as they trickle in
[21:05] <kirkland> soren: vlan, i don't know, whatever someone's going to come up with
[21:05] <soren> Right, ok.
[21:05] <kirkland> okay so....
[21:05] <kirkland> per the success criteria above, mathiaz has a package that's looking pretty good
[21:05] <kirkland> grant it, we've only tested with default network
[21:05] <kirkland> but EtienneG has offered to help us with some other scenarios
[21:05] <kirkland> bonded, for instance
[21:05] <kirkland> if you wish, i suppose we can test that in a PPA?
[21:06] <kirkland> would that make you feel better than uploading to Jaunty?
[21:06] <soren> that's a really good idea.
[21:06] <soren> Much.
[21:06] <kirkland> okay, we can do that, gather some data points
[21:06] <kirkland> heck, blog about it on ubuntu-server
[21:06] <EtienneG> going to test it in a minute, my intrepid vm is updating right now
[21:06] <soren> The fewer upgrade cases to worry about, the better. Especially the ones that mess around with rc?.d/* symlinks.
[21:07]  * kirkland steps off the pulpit
[21:07] <soren> kirkland: Can you give me the quick 5 points on how mathiaz's package does things now?
[21:07] <mathiaz> EtienneG: the packages I've put on people.ubuntu.com have been compiled for jaunty
[21:07] <mathiaz> soren: open-iscsi is started after S40Networking
[21:08] <mathiaz> soren: open-iscsi init script takes care of mounting the _netdev entries in fstab
[21:08]  * kirkland will let mathiaz take this one, and fly wingman
[21:08] <mathiaz> soren: this is what debian is doing for now.
[21:08] <soren> Yes.
[21:08] <mathiaz> soren: for the shutdown sequence, open-iscsi is shutdown after umountnfs and sensigs
[21:09] <mathiaz> *sendsigs*
[21:09] <mathiaz> soren: umountnfs.sh takes care of umounting netdev filesystems
[21:09] <mathiaz> soren: and sendsigs won't kill the iscsid daemon
[21:09] <soren> mathiaz: What if /usr is on iscsi?
[21:11] <mathiaz> soren: do script run after S32open-iscsi rely on /usr available?
[21:11] <soren> After S35mountall.sh.
[21:12] <mathiaz> soren: the next one S40umountfs states that it doesn't rely on /usr
[21:12] <soren> mathiaz: S40umountfs?
[21:12] <soren> Where's that?
[21:12] <mathiaz> soren: /etc/rc6.d/
[21:12] <mathiaz> soren: and actually you have the same problem if /usr on mounted via nfs
[21:12] <soren> Er... WE're talking about bootig here?
[21:12] <soren> booting.
[21:12] <mathiaz> soren: no - shutdown
[21:13] <soren> Oh.
[21:13] <soren> I'm not :)
[21:13] <soren> no point in worrying about shutting down if we can't boot properly yet :)
[21:13] <mathiaz> soren: sure - so how is /usr on nfs handled?
[21:13] <espacious> so soren http://pastebin.com/f3ebe2c3d , http://pastebin.com/fa975495 , http://pastebin.com/f695ade99
[21:14] <mathiaz> soren: in that case it's S45mountnfs.sh that is takes of mounting /usr from nfs
[21:14] <EtienneG> mathiaz, damn developer and their bleeding edge stuff!
[21:14] <soren> mathiaz: Probably not very well anymore.
[21:14] <soren> mathiaz: That's a poor excuse to break it for iscsi too, though :)
[21:14] <espacious> soren i think the partitions shoud be Raisd autodetect not LVM or what?
[21:14] <EtienneG> just curious: are you guys going to go with marking fs on iscsi target with _netdev and delaying mount until all of networking is up?
[21:15] <mathiaz> EtienneG: yes
[21:15] <kirkland> EtienneG: right
[21:15] <EtienneG> mathiaz, now I love you
[21:15] <soren> please, please, please.... no.
[21:15] <mathiaz> soren: so how do you wanna handle that then?
[21:15] <soren> handle what, exactly?
[21:16] <mathiaz> soren: what EtienneG just said
[21:16] <soren> Handle marking stuff as netdev and postponing mounting?
[21:16] <soren> I wouldn't.
[21:16] <mathiaz> soren: yes - and waiting for S40networking
[21:16] <soren> I wouldn't.
[21:16] <mathiaz> soren: before starting any iscsi device
[21:16] <soren> I wouldn.t
[21:17] <mathiaz> soren: the other option is to use if-up.d
[21:17] <soren> *a* other option.
[21:17] <soren> Possibly a good one.
[21:17] <mathiaz> soren: if so, we'd have to teach mountnfs.sh to wait for netdev filesystem to come up.
[21:18] <mathiaz> soren: and we'd also have to come up with a way to make sure that iscsi block device are available before keeping booting
[21:18] <soren> Yes.
[21:18] <mathiaz> soren: the use case here being that some application may wanna use the raw block device
[21:18] <mathiaz> soren: and so we have to make sure that the iscsi block device is there
[21:18]  * soren is very confused
[21:18] <mathiaz> soren: AFICT there isn't such a facility for now
[21:18] <soren> You ask me...
[21:19] <soren> and I explain at great lenght what I'd do...
[21:19] <soren> and you decide to do the complete opposite.
[21:19] <soren> Why do you ask?
[21:20] <soren> I said, and still believe that marking things in fstab as netdev, postponing mounting until after S40, etc, etc. is exactly how you'd do it 15 years ago.
[21:20] <soren> We've changed everything else in Ubuntu to happen at discovery time. This has brought us loads of cool stuff.
[21:20] <mathiaz> soren: ok - so what you suggested to make sure that the iscsi devices pop up in time
[21:21] <soren> We no longer have to hardcode raid configurations and whatnot... We configure stuff as it pops up and that magically makes everything available when we want to mount it.
[21:21] <soren> i dont' see why we'd go the complete opposite direction with iscsi.
[21:21] <mathiaz> soren: ok - so I've got some working code to that integrates with if-up.d
[21:22] <mathiaz> soren: we get to the point where the iscsi block device are created
[21:22] <soren> does it involve marking stuff as _netdev?
[21:22] <soren> In fstab?
[21:22] <EtienneG> the drawback being that you have to fix each networking use-case piecemeal, and leave people with some esotoric network setup in the cold
[21:22] <mathiaz> soren: yes - because the mountfs script if ifup.d takes care of mounting netdev devices
[21:22] <EtienneG> (ie, wpasupplicant, various vpn and stuff)
[21:22] <soren> EtienneG: Noone said making an operating system was easy.
[21:23]  * soren sobs
[21:23] <soren> It's pointless.
[21:23] <mathiaz> soren: the other option is to teach udev to mount the device
[21:23] <soren> it's an annoying thing to have to implement in the installer, and if we do the other stuff right, it's not necessary.
[21:23] <soren> mathiaz: No. The other option is to make sure that the device is there and ready when *everthing* else is mounted.
[21:24] <soren> Your if-up.d trick might very well do that.
[21:24] <soren> I'm starting to like the sounds of it.
[21:24] <Jeeves_> I might have missed half the discussion
[21:24] <mathiaz> soren: ok - but then how do you make sure that when mountall.sh waits for all the devices to be there?
[21:25] <Jeeves_> But how is iscsi really different from nfs?
[21:25] <soren> mathiaz: udevadm settle, probably.
[21:25] <Jeeves_> (Shut me up if needed)
[21:25] <soren> Jeeves_: For one thing, you have a regular filesystem on iscsi.
[21:25] <soren> iscsi provides block devices.
[21:25] <EtienneG> Jeeves_, iscsi expose block devices, nfs expose file syste,
[21:25] <soren> nfs is easy to recognise in fstab.
[21:25] <soren> ...which has allowed for shortcuts earlier.
[21:26] <EtienneG> basically, iscsi make network block device look like they are local
[21:26] <soren> mathiaz: Or we could spin waiting for stuff to turn up if we wanted to.
[21:26] <mathiaz> soren: hm - you may hit race condition, because while isciadm is logging  into the target udev doesn't know that there is device to be settled
[21:26] <EtienneG> an iscsi target would show up as /dev/sdb, /dev/sdc, etc
[21:26] <soren> mathiaz: We do for the root filesystem anyway.
[21:26] <Jeeves_> ah right
[21:26] <Jeeves_> missed that bit :)
[21:27] <soren> mathiaz: These are tiny details. I'm sure there's a way to query iscsid asking it if it's about to login somewhere or not.
[21:27] <mathiaz> soren: well - the list of target to logged in can be retrieved easily
[21:28] <soren> mathiaz: We can even add a special piece of code that puts a lock file somewhere when we call the initiator thing and remove it when it's done and wait for it to disappear before we go on to mountall.
[21:29] <EtienneG> mathiaz, in any case, is there still any value in me testing whatever you did today?
[21:29] <mathiaz> soren: that means sticking another init script in rcS before mountaall
[21:29] <mathiaz> EtienneG: yes
[21:29] <mathiaz> EtienneG: I'd like to know what happens when multiple interface are used
[21:29] <soren> mathiaz: Really? Couldn't we do it in the current open-iscsi script?
[21:29] <EtienneG> mathiaz, ok, but I will postpone until tomorrow if you do not mind.  Also, could you post the URL again, it is lost in the scrollback :(
[21:29] <soren> mathiaz: ...which is at S25.
[21:30] <mathiaz> EtienneG: whathever solution we choose, we'll run in the same issue when iscsiadm tries to connect to a target with multiple interfaces
 EtienneG: could test the open-iscsi package from http://people.ubuntu.com/~mathiaz/packages/?
[21:30] <EtienneG> thanks
[21:30] <kirkland> EtienneG: bonded ethernet would be nice if you could test that one
[21:30] <kirkland> EtienneG: bridged too, if possible
[21:30] <mathiaz> soren: well - we'd have to refactor the init script completly
[21:31] <mathiaz> soren: the current init script should be moved to if-up.d
[21:31] <mathiaz> soren: as it's responsible for starting the iscsid daemon if it's not running
[21:31] <mathiaz> soren: and then logging  into the target
[21:31] <soren> mathiaz: Right.
[21:31] <soren> mathiaz: I don't mind changing things :)
[21:31] <mathiaz> soren: we'd have to add another init script at S25 that waits for all the iscsi devices to be up
[21:32] <soren> mathiaz: Especially if those things are things that is involved in booting and we inherited it from Debian.
[21:32] <EtienneG> kirkland, yeah, I will try to setup a testbed with both
[21:32] <soren> mathiaz: All the ones that are on their way, yes.
[21:33] <mathiaz> soren: hm - that should be possible then
[21:33] <soren> It's very possible. In fact, I doubt it's more than a couple of days work.
[21:36]  * soren runs for a few minutes
[21:37]  * kirkland -> goes get a late lunch
[21:41] <soren> mathiaz, kirkland: So I think we're pretty much on the same page now?
[21:43] <soren> Plan is: Fix ifenslave-2.6 to configure stuff asap (a.k.a. when the last slave turns up). Put iscsi initiation thing into an if-up.d script. Replace the existing S25open-iscsi with something like "udevadm settle; <something that waits for running iscsi logins to finish>" ?
[21:46] <soren> EtienneG: Doing it the Debian way might solve a specific problem you have at hand, but it fails in many other ways. It works no matter how obscene your network setup is, but it doesn't work at all for people who need it for /usr, /var or anything else that's expected to be around waaay before S40networking is run.
[21:48] <soren> EtienneG: I don't think this is a matter of choosing one over the other. This is a matter of fixing this to happen in the order required to make any use case work.
[21:48] <EtienneG> soren, could be.  In the end, I do not care about the Ubuntu way or the 15-years-ago way of doing it, I just care about getting it to work in a general fashio
[21:48] <EtienneG> otherwise, it is not fixed, it is just a problem waiting to happen
[21:49] <EtienneG> if you think your way does it, I am good with it
[21:49] <soren> Back in the day, there were init scripts for mdadm and lvm. They were run in that order. You had to put your mdadm config into a config file. If you wanted to stack things in more layers than that, or if you wanted mdadm on top of lvm, you lost.
[21:50] <soren> In fixing that, there were a few cases here and there that failed for a while, but the end result is a *very* flexible system that allows you to stack things in any way you please, because we don't care about the ordering anymore.
[21:51] <soren> This paradigm started to work its way into networking, when udev started configuring things as they turned up.
[21:52] <soren> Someone (who shall remain unnamed right now) put in a "fix" that stopped this from happening, effectively bringing back networking to the "one way or the highway" paradigm.
[21:57]  * soren goes to bed
[23:24] <RediXe> Using rsync, I can rsync my home directory on my desktop to my server, how can I then pull that home directory off the server and on to my laptop?
[23:25] <Kamping_Kaiser> sure.
[23:28] <hads> `rsync server:. .`
[23:29] <hads> Something along those lines
[23:29] <dana_good> rsync server /home/redixe
[23:30] <dana_good> something like that
[23:30] <hads> That doesn't involve a remote source
[23:31] <hads> OK, I forgot the -a switch on mine.
[23:51] <Kamping_Kaiser> rsync -avz --progress $PATHIN server:$PATHOUT
[23:58] <hads> rsync -Pav server:. .