#maas 2012-08-20 <roaksoax> morning <roaksoax> allenap: howdy <allenap> roaksoax: Hello :) Good holiday? Ready for busy week? <roaksoax> allenap: yes indeed a good holliday, thanks for asking <roaksoax> allenap: and yeah, ready :) <roaksoax> allenap: any updates ? <allenap> roaksoax: Don't really know where to begin. Let's have a call. Are you free in 15 minutes, 1315 UTC? <roaksoax> allenap: would it be possible at 1330 utc? <roaksoax> allenap: until what time are you gonna be around? <allenap> roaksoax: Sure, 1330 is fine. <roaksoax> allenap: ready when you are <allenap> roaksoax: https://plus.google.com/hangouts/_/41241d8291d05125cc44ff76b99f961d1359ff51?authuser=0&hl=en-GB <roaksoax> allenap: browser crashed <roaksoax> allenap: what happen with python-tx-tftp? <allenap> roaksoax: He hasn't been in touch for a good long time. We shall have to work from my branch. Can we just ship it within maas for now? <roaksoax> allenap nope leta jjst keep patching it in quantal <allenap> Okay. <allenap> roaksoax: Also, <allenap> Ach, <allenap> roaksoax: Did you have a look at the commandant package? <roaksoax> allenap nopr i didnt have the time <allenap> roaksoax: It's something that I'd like for 12.10, but not for the 12.04 point release, so don't work on it this week :) I'll bother you again next week, if you don't mind. <roaksoax> please do ;) #maas 2012-08-21 <rbasak> smoser: maas-import-ephemerals uses https, which can go through a proxy but cannot be cached. maas-import-pxe-files currently uses http so caching does work. Thoughts? <lifeless> rbasak: https is cachable. <smoser> rbasak, https_proxy <smoser> at least i think i've tested that. <smoser> rbasak, the reason it goes through https was a shortcut. <rbasak> It is? <rbasak> I mean cached by a proxy <lifeless> rbasak: yes, two ways. You can talk https to the proxy, you can have a MITMing proxy. <lifeless> either will get the proxy visbility into the requests and let it cache. <smoser> i didn't have time to implement any signature checking of hashsums. <rbasak> lifeless: sure, I understand that. But is there a trivial way of making this work with wget? <smoser> so i had to transfer securely. <rbasak> smoser: OK. I'm just wondering if this has any implications that haven't been considered <smoser> rbasak, does 'https_proxy: http://your.proxy:3128/ wget https://foo.bar' not work? <rbasak> smoser: yes, it does - but the proxy can't cache anything then <smoser> i'm assuming you tried that, and assuming that i'm looking incredibly ignorant to lifeless. <smoser> :) <rbasak> it just passes the tcp connection thruogh <smoser> i have to run for a bit. <rbasak> ok <smoser> rbasak, i want to get checking done though. <smoser> gpg checking signatures. <smoser> cloud-utils now has the public key installed. <rbasak> Yes. <smoser> of the cloud build system. <rbasak> But what about the pxe files? <smoser> later. <smoser> have to look more. dont know off top of my head. <smoser> talk later. <rbasak> OK enjoy your run :-P <roaksoax> allenap: howdy <allenap> roaksoax: Hello! <allenap> roaksoax: How is the package looking? <roaksoax> allenap: looking good <roaksoax> was just wondering whether there are any other config options that need to be updated <roaksoax> allenap: And if there's any new files that need to be installed, have they been added to setup.py? <allenap> roaksoax: pserv.yaml grew tftp options, but that was a while ago. Check celeryconfig.py perhaps? <allenap> roaksoax: I would hope they're in there. I'll have a look. <roaksoax> allenap: right but I meant if any of the config options need to be changed on package configuration <allenap> roaksoax: Can you give an example of what you mean? <allenap> I have to reboot; biab. <allenap> Back. <roaksoax> allenap: stuff that gets modified on maas.postinst file <allenap> roaksoax: Anything relating to cobbler can be removed. This is probably the wrong way to do it, but here's a start: http://paste.ubuntu.com/1159210/ <roaksoax> allenap: heh, I alread have that removed :) at least most of it <roaksoax> allenap: am testing it though <allenap> roaksoax: Cool :) <roaksoax> allenap: maas_local_settings has changed right? <roaksoax> allenap: ah so -PSERV_URL = "http://maas:password@localhost:5241/api" was cobbler specifig? <roaksoax> allenap: wasn't that the user/password to access pserv itself? <roaksoax> as in, authenticated provisioning server API access <allenap> roaksoax: Yeah, but the original purpose of pserv was as a not-insane wrapper around cobbler. That part has now gone, but pserv lives on as the dynamic tftp server. <roaksoax> allenap: gotcha, so the user/pass features for pserv.yaml are gone too <allenap> roaksoax: Yep. <roaksoax> alright then <roaksoax> that's something that you did remove and I didn';t :) <roaksoax> allenap: did you make any further changes to python-tx-tftp in maas trunk? <allenap> roaksoax: Not since 27th July. <allenap> r780 <roaksoax> allenap: could you please check the package in ubuntu quantal, (the patch in the package actually) <roaksoax> allenap: the tftp configuration is not enabled by default on pserv.yaml <roaksoax> ? <roaksoax> or does it use default values? <allenap> roaksoax: It uses default values. <roaksoax> allenap: alright, now, was the DNS server disabled by default <roaksoax> ? <allenap> roaksoax: I don't have a quantal install available right now, and for this week at least we just need to get it working on precise. <allenap> roaksoax: Ah, DNS, I don't know. Can you ask Julian and Jeroen via maas-devel? <roaksoax> allenap: will do <roaksoax> allenap: /usr/sbin/maas-import-pxe-files: line 38: MAAS_PROVISIONING_SETTINGS: parameter null or not set <allenap> roaksoax: Ah, right, we have to wrap that script using maas-provision. Please can you file a critical bug about that? <roaksoax> allenap: hold on, what do you mean :) <roaksoax> allenap: maas-provision binary exists: http://paste.ubuntu.com/1159352/ <allenap> roaksoax: I mean that maas-import-pxe-files is not suitable for being run by users any more; it should be called by maas-provision. <allenap> roaksoax: Something like: maas-provision import-pxe-files ... <roaksoax> allenap: ok <roaksoax> allenap: that's packaging side then <roaksoax> allenap: so are we looking into integrating maas-import-pxe-files inside maas-provision or just call it as a script <roaksoax> allenap: ^^ <roaksoax> allenap: another error: http://pastebin.ubuntu.com/1159370/ <allenap> roaksoax: It'll just be called as a script, but by maas-provision, which will ensure that MAAS_PROVISIONING_SETTINGS is correct. <roaksoax> allenap: ok <allenap> roaksoax: That looks like dnssec-keygen is missing, from bind9utils. <roaksoax> allenap: it is not :) <roaksoax> allenap: and as far as i can recall we agreed with rvba to not do that on maas-installation <roaksoax> cause that would need bind9utils installed <roaksoax> when it is not needed <roaksoax> allenap: ok, found the fix <allenap> roaksoax: This is happening when Apache starts, isn't it? <roaksoax> allenap: i thought rvba fixed it <allenap> Oh good :) <allenap> roaksoax: I guess not, and he's surfing for the next 10 days or so :) <roaksoax> allenap: yeah it is lacking of full path for dnssec-keygen but we had a way to had that fix <roaksoax> so rvba was gonna fix it ) <roaksoax> :) <allenap> roaksoax: Critical bug, unless the fix is okay. <roaksoax> allenap: yeah I have ogt remember how we agreed to fix it <roaksoax> allenap: for now i'll just patch the package <allenap> roaksoax: I'll be back online later, probably. If you hit any more problems like those, file them as Critical. <roaksoax> allenap: will do <guimaluf> if I put a 'in-target wget http/.../' inside my preseed file, the node can't get my file. what should I do to make my files avaible? <robbiew> "Andres Rodriguez has proposed merging lp:~andreserl/maas/packaging_cobbler_removal into lp:~maas-maintainers/maas/packaging." \o/ <allenap> \m/ * flacoste changed the topic of #maas to: 6 weeks until Final Freeze | Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/ #maas 2012-08-22 <m4fiya> Hey is there anyone that could help me with setting up MAAS on virtual box im having a major issue <bigjools> I can't think why it would suddenly stop working - can you paste a screen shot of the failure? <bigjools> what path is it using to TFTP the boot image? <m4fiya> bigjools, is that directed at me? <bigjools> m4fiya: ^ <m4fiya> oh okay, i didn't think i had to setup the path specfically, shouldn't it do this automatically? <bigjools> it does, but if it can't find an image then either the image is missing or the TFTP path went wrong <bigjools> I've not encountered either of these types of failure before <bigjools> are you using the 12.04 package? <m4fiya> yes I am <bigjools> usually when booting the console will say what path it's using to try and download a boot image <bigjools> see if you can find that under /var/lib/tftpboot <m4fiya> hmm, I'm guessing thats not something Virtual Box does <bigjools> damn <m4fiya> would VMware do this? <bigjools> no idea, sorry. <bigjools> I've mostly been testing with real hardware lately <m4fiya> We can't all be that lucky ;) <bigjools> heh <bigjools> I do want to make sure the VM stuff works though <bigjools> it's definitely trying to PXE boot? <m4fiya> I have turned every other type of boot off but the hard disk <bigjools> that's your problem then <bigjools> boot order should always be PXE <m4fiya> I mean other then Hard disk and PXE <bigjools> PXE first - in fact that's all you need <bigjools> since the server uses chain.c32 to make it local boot when necessary <m4fiya> Also is there specific DHCP setting I need to make on my router? <bigjools> it should be fine if you already enlisted a node <bigjools> the "next-server" setting tells clients where to TFTP images from <m4fiya> im going to try and use VMware and see if it works <m4fiya> I have tried on multiple machines, one running Ubuntu as the Host and one running Windows as the Host <m4fiya> Now it seems like DHCP is failing <bigjools> that won't help <bigjools> can you delete the node and re-enlist it? <bigjools> to see if anything changed in your environment <m4fiya> Well i just tried to install a new node, and it seems like the DHCP service is failing, does the MAAS management server need to be the DHCP? <bigjools> no, it can be remote <m4fiya> does this need to be specified, or does it auto DHCP <bigjools> but as I said the next-server needs to be configured, or nothing will be able to PXE boot <m4fiya> what is the next-server? <bigjools> it tells the client where to TFTP a boot image <bigjools> it is the MAAS server <m4fiya> oh okay, well i have the MAAS server up and running <bigjools> does your DHCP server have this setting? <bigjools> if it's in your router it might be called something else <m4fiya> it doesn't seem like it does have a setting like that <m4fiya> by default does the MAAS server try to act as the DHCP? <bigjools> it can do if you want <bigjools> I can't remember if that's default or not <bigjools> if you look in /etc/cobbler/settings there's a manage_dhcp setting <bigjools> I have to run out for 30 minutes, will help later if you're stiull stuck <jtv> allenap: here's a first attempt to âmake runâ and then ctrl-C. It didn't get very far (looks like rabbit doesn't run by default on my system, for whatever reason) but the problem occurs. This is on a freshly booted system: http://paste.ubuntu.com/1160493/ <jtv> The first ctrl-C gave me â--> Stop `celeryd`â <jtv> And then a second one got me back to the command prompt. <jtv> If I don't do that, things seem to hang indefinitely. <jtv> I'll reboot now to clean up, and try to give you a less noisy run with rabbit started. <jtv> allenap: âmake distcleanâ also hangs while killing celery. <jtv> allenap: better log here, after starting rabbit manually â http://paste.ubuntu.com/1160508/ * allenap is looking now <jtv> allenap: killing the âsuperviseâ process for celery gets the shutdown going again, but doesn't remove those /run/lock/maas.dev.* files. <jtv> Hmm... nor does it kill all celery processes. <allenap> jtv: I'm looking at signal handling in celery at the moment, to see if it responds to the correct signals. <jtv> Thanks. <allenap> jtv: Signal handling is fine, it's attempting a "warm" shutdown, but it's stuck on accept(...) from /tmp/pymp-m1mA71/listener-_H1dxR (on my machine). The "pymp" bit there suggests it's a multiprocessing socket. All the child processes are defunct, so it hasn't collected them yet. Something's funky. <jtv> It should come out of the accept() with EINTR, no? <allenap> jtv: I guess so, but perhaps it's doing something "clever". <jtv> Yeah. Might even be the sort of thing that newer interpreter versions helpfully hide. <jtv> allenap: interesting news on my front is that the bulk of datagram-received messages comes from bootstrap.py. Almost as if some work is being done over and over again that should be delegated just once. <allenap> jtv: Yes, there is some element of that iirc. <jtv> Getting the feeling that the âsessionâ was supposed to take over after bootstrapping, but instead, the bootstrapping packet-handling code remained in front of the session's for convenience. <jtv> Maybe because the concrete bootstrapping class keeps checking if this packet is the initial one. If that could be moved into the base class, maybe the division of labour could be more effective. <allenap> Erm, python-celery appears to still be in universe. <jtv> allenap: that sounds a bit like a complication <allenap> Indeed, a fairly big one :) <rbasak> smoser: when you get in, I need ephemeral images published for armhf+highbank. What's involved for this? <allenap> Gah, now the webapp won't stop... because it's hanging on an accept(). <rbasak> Yeah I got that <allenap> Again, related to multiprocessing. <rbasak> Standard process seems to be to pkill -9 celeryd, find the webapp and kill that, then rm /run/lock/maas* <rbasak> python is very bad at doing the right thing by default with signals when its using threads <allenap> http://paste.ubuntu.com/1160627/ fixes the webapp problem (though it also stops the cache from working). <allenap> http://paste.ubuntu.com/1160632/ fixes the celeryd shutdown problem. <allenap> jtv: ^ <jtv> allenap: where âtheâ cache is which? <jtv> Ahhh, it's the Manager that's holding things up then? <jtv> Damn. I liked the shared-memory solution â not sure why we ended up with the Manager in the first place. <allenap> jtv: Only in the webapp, where it's not needed. That change didn't help getting celeryd to stop. <jtv> Maybe it should have been a property, so that at least it doesn't get created until used. <allenap> Right, lunch time here. <allenap> Yeah. <jtv> Thanks for figuring this out. I'll see if that change happens to be low-hanging fruit. <jtv> Oh bugger no it isn't. <roaksoax> howdy <roaksoax> allenap: http://paste.ubuntu.com/1160673/ --> so that's maas-provision <roaksoax> allenap: where from will it export the MAAS_PROVISION_SETTINGS <guimaluf> if I put a 'in-target wget http/.../' inside my preseed file, the node can't get my file. what should I do to make my files avaible to nodes? <allenap> roaksoax: I have to go out now. I'll be back in ~4h, and I'll try to sort out the MAAS_PROVISIONING_SETTINGS problem then. Would you be able to document how we can build the packaging recipe locally, ourselves? <roaksoax> allenap: bzr bd ? <roaksoax> :) <roaksoax> allenap: it failed to build because I forgot to commit a patch <allenap> roaksoax: Is that it? I know almost nothing about packaging, so baby steps please :) * allenap goes. <roaksoax> allenap: let me know when you are around again <allenap> roaksoax: I'm back. <roaksoax> allenap: https://code.launchpad.net/~andreserl/maas/maas_lp1040047/+merge/120769 <roaksoax> please :) <allenap> roaksoax: On it :) <roaksoax> allenap: thanks! :) <allenap> roaksoax: Btw, I realised earlier that python-celery is in universe. MAAS depends on it now. Do we have any plans around that? <roaksoax> allenap: python-celery is in main afaik <roaksoax> allenap: apt-cache show python-celery | grep main <roaksoax> Filename: pool/main/c/celery/python-celery_2.5.3-1ubuntu1_all.deb <allenap> roaksoax: I wonder why I'm not seeing that. I've got 2.4.6-1 in universe here. Are you looking at Precise? <roaksoax> allenap: in precise is in universe <allenap> Ah. <roaksoax> allenap: and since we are not SRU'ing maas, there's no need to deal with it now :) <roaksoax> allenap: in quantal is in main <allenap> roaksoax: I thought we *were* SRU'ing it. <allenap> That's what we've been pushing towards this week. <roaksoax> allenap: not for 12.04.1 <allenap> roaksoax: No, we've missed that :-/ But can we get python-celery into main now? <roaksoax> allenap: well that's a whooooooooole different problem <roaksoax> allenap: technically we can't <roaksoax> but its been done before afail <roaksoax> afaik <roaksoax> allenap: that's something Daviey or smoser will have to take care of though <allenap> I shall await comment from them :) <roaksoax> allenap: btw.. as soon as the patch above lands ai can rol packages <roaksoax> i'm off to lunch now though <allenap> roaksoax: Cool. I'll be having dinner soon, but I'll be back once the kids are in bed. <roaksoax> allrnpa the fix above we discussed the same with rvba and smoser <roaksoax> cant recall but i think wr agreed not to do tjat <smoser> clearly bigjools missed the "not going to SRU" memo. <smoser> i dont know if daviey agreed to that or not, and i definitely understand pressure to get new maas into 12.04. <smoser> however, it clearly does not follow the "stable release update" path. <allenap> smoser: I think we all - Red and flacoste - missed that memo :) * allenap will be back in ~2h <smoser> well, we clearly missed 12.04.1 <smoser> and it clearly does not really fit SRU https://wiki.ubuntu.com/StableReleaseUpdates <smoser> personally, i feel the best way to service 12.04.1 maas with current maas trunk is via ppa. <smoser> but i suspect that is not popular. <roaksoax> /me is eating mexican food for smosers amusement <smoser> and i'm sure that rules could be bent to accomodate the main dependency. i just dont know about the value of bending the rules. <guimaluf> if I put a 'in-target wget http/.../' inside my preseed file, the node can't get my file. what should I do to make my files avaible to nodes? <smoser> guimaluf, what is wrong with the wget? is dns failiing? you can try wget outside and then copy in <guimaluf> smoser, proxy issue <guimaluf> it cant hit the file <guimaluf> Aug 20 17:28:42 node-782bcb77e1d4 in-target: --2012-08-20 14:28:42-- http://575.979.1648/cblr/aux/postscript.sh <guimaluf> Aug 20 17:28:42 node-782bcb77e1d4 in-target: Connecting to 575.979.1648:8000... <guimaluf> Aug 20 17:28:42 node-782bcb77e1d4 in-target: connected. <guimaluf> Aug 20 17:28:42 node-782bcb77e1d4 in-target: Proxy request sent, awaiting response... <guimaluf> Aug 20 17:28:42 node-782bcb77e1d4 in-target: 403 Forbidden <guimaluf> Aug 20 17:28:42 node-782bcb77e1d4 in-target: 2012-08-20 14:28:42 ERROR 403: Forbidden. <roaksoax> allenap: so I just saw your diff and seems reasonable. However, will that add /usr/sbin to the path to everything else that is run, or just for that command in particular? <smoser> guimaluf, is it just that url? <guimaluf> smoser, yep <guimaluf> smoser, anyway my maas server can't deploy the ssh-pubkey and I cant download files in that manner <smoser> guimaluf, is your system clock on the target reasonably set? <guimaluf> yes <guimaluf> the clock was my first big issue setting up maas. <guimaluf> I fixed in many ways. the ephemeral disk.img has the pre-start ntpdate script. <guimaluf> but maybe isnt enough <allenap> roaksoax: Just for that command. <allenap> roaksoax: Btw, we often +1 merge proposals with comments that need to be acted on. If we were being strict we'd mark them as Needs Fixing, but we approve them so that we don't block each other as the world turns. <roaksoax> allenap: ok, since you alread proposed an alternate fix, could you propose a branch? <allenap> roaksoax: Okay, I'll do that. Can you email the list instructions on how to build the package? <allenap> locally. <roaksoax> allenap: will do by EOD <allenap> roaksoax: Thanks. <roaksoax> allenap: btw.. are you committing the env change today? <allenap> roaksoax: I can, if you need it? <roaksoax> allenap:no not really <roaksoax> allenap: i do need you to approve something before yo leave <roaksoax> allenap: https://code.launchpad.net/~andreserl/maas/packaging_bzr911/+merge/120865 * allenap looks <allenap> roaksoax: Approved. If someone isn't around I'd say it's safe to self-approve those and keep moving. <roaksoax> allenap: thanks <roaksoax> allenap: i thought self approving didn't work :) <allenap> roaksoax: I do it from time to time. <roaksoax> allenap: good to know. cause i thought the lander didn't process those self approved MP's <allenap> roaksoax: Could you look at https://code.launchpad.net/~allenap/maas/alt-fix-for-maas_lp1040047/+merge/120866? I am doing it after all, before I forget. <roaksoax> allenap: looks good to me, has it been tested? <allenap> roaksoax: Yes. <allenap> roaksoax: Ah, you mean, is there a test for it. No, not specifically. <allenap> The code is exercised, but that specific behaviour is not checked. <allenap> roaksoax: I'm signing off now. Have a good evening! <roaksoax> allenap: you do aswell #maas 2012-08-23 <roaksoax> allenap: any luck with the fix for maas-import-pxe-files? That's what I need to test in order to ceritify it is working <allenap> roaksoax: I'll do that now. <roaksoax> allenap: cool thanks <allenap> roaksoax: Is that https://bugs.launchpad.net/maas/+bug/1040462? Or the MAAS_PROVISIONING_SETTINGS one? <ubot5> Ubuntu bug 1040462 in MAAS "maas-import-pxe-files blows up (packaged version)" [Critical,In progress] <allenap> Both need to be done... <roaksoax> allenap: right so running sudo maas-provisiong install-pxe-image alone fails too <allenap> The latter bug is https://bugs.launchpad.net/maas/+bug/1032462 <ubot5> Ubuntu bug 1032462 in MAAS "MAAS_PROVISIONING_SETTINGS: required but not set and not documented?" [High,Triaged] <roaksoax> smoser: have you ever done something like: Package A version 1 Depends on B, then Package A version 2 no longer Depends on B. So on upgrade, remove package B automatically <smoser> i dont think you can cause the removal <melmoth> is not aptitude suppose to do this kind of stuff on its own ? <melmoth> i always use apt-get, but last time at a local lug, people told me that was one of the benefit of aptitude <melmoth> i did not check if i understood correctly what i heard though. <roaksoax> it is supposed to <roaksoax> I was thinking that a simple COnflicts/Replaces woiuld do, but my tests failed, so I consulted, and it should actually work <melmoth> if one can call dpkg -l from within a postinst script, one should be able to test wether package B is installed, and try to uninstall it. <melmoth> but i smell locking problems of some sort. <melmoth> Grmblblbl... When i juju deploy a service (within maas if that matter), how does the new system decide to install the regular version of juju, or the ppa one ? <melmoth> or, may be to ask it in a more clear way: "how does the new system decide to install some ppa or not". where does it get this information from ? <roaksoax> melmoth: right so using dpkg -i in my particular case was plain wrong :) <roaksoax> allenap: alright, i'm only waiting that fix and everything else should be fine <allenap> roaksoax: Yeah, I'm having to put kids in bed and such. <roaksoax> allenap: no worries <allenap> roaksoax: Simple fix! /usr/sbin/maas-provision, last line, should have "$@" appended. <allenap> (including quotes) <allenap> That doesn't fix the MAAS_PROVISIONING_SETTINGS problem, but I'll do that later. <allenap> roaksoax: If you don't get to it in the next hour, I'll propose a merge against the packaging branch. <roaksoax> allenap: lkike this? http://paste.ubuntu.com/1163087/ <roaksoax> allenap: btw.. maas-provision and its dependencies have to be removed on upgrade right? Otherwise, things like tftp will overlap <allenap> roaksoax: Yes, but you need to add "" quotes around the $@. <roaksoax> allenap: ok, so on the other hand <roaksoax> allenap: the tftp server doesn't seem to be working <allenap> roaksoax: Oh, jolly good :) <roaksoax> allenap: DNS doesn't have access to do what it needs to do <roaksoax> allenap: are we assuming that MAAS will handle both DNS/DHCP simultaneoulsy or can it do it separately <allenap> roaksoax: The TFTP port needs setting to 69 in /etc/maas/pserv.yaml. <roaksoax> allenap: could you change that in trunk? <allenap> roaksoax: The tftp/generator setting in pserv.yaml needs setting too. <allenap> roaksoax: etc/pserv.yaml in trunk is configured for development. I can add another file, pserv.prod.yaml, or something like that. I can't change etc/pserv.yaml without upsetting several other things (i.e. it can be done, but it's not going to be quick). <allenap> roaksoax: One other thing: maas (the package) does not depend on wget, but the scripts need it. <roaksoax> allenap: i'll do it in packaging <roaksoax> allenap: could you provide a diff? <roaksoax> allenap: IMHO, the settings file should all be production in trunk <allenap> roaksoax: Actually, I'm changing it in trunk. You'll still need to patch it, but it'll be more obvious. <allenap> Having it all production in trunk makes development a little challenging. <roaksoax> allenap: they shouldn't differ IMHO <roaksoax> allenap: please, just send me a diff that I'll need to apply <roaksoax> allenap: now, for the DHCP stuff, do we want to keep the debconf config like stuff? <roaksoax> i thought this was gonna be done through the WebUI <allenap> roaksoax: I don't know. I haven't used the debconf stuff for that yet. <roaksoax> allenap: right, but my point being is that how are we planning to configure DHCP <roaksoax> simply do it manually with maas-provision generate-dhcp-config? <allenap> roaksoax: Leave it at that for now. <roaksoax> allenap: ok bigjools was pointint stuff about that <roaksoax> so that's why I was checking <allenap> roaksoax: https://code.launchpad.net/~allenap/maas/default-to-production-config/+merge/121080 will make the default configuration production-ready. Then you can patch out the custom settings of tftp/port and tftp/generator, and it ought to work. <roaksoax> allenap: ok <allenap> roaksoax: Once that's landed, you can apply the following additional patch: http://paste.ubuntu.com/1163300/ <roaksoax> allenap: shouldn't we uncomment the #port and #generator? <allenap> roaksoax: They'll default to the same things. <roaksoax> allenap: ok, with that I get : "Unable to locate configuration file" while pxebooting <allenap> roaksoax: That /may/ be unrelated to this. Can you try: curl 'http://localhost/MAAS/api/1.0/pxeconfig/?mac=12:34:56:78:90:ab' <roaksoax> allenap: No provided arch! <allenap> roaksoax: Ah, okay, the next branch hasn't landed yet ;) Try: curl 'http://localhost/MAAS/api/1.0/pxeconfig/?mac=12:34:56:78:90:ab&arch=i386&subarch=generic' <roaksoax> allenap: http://pastebin.ubuntu.com/1163315/ <roaksoax> erro <roaksoax> allenap: No provided arch too <roaksoax> allenap: ok so we have a broken tftp server then <roaksoax> allenap: also please check that the changes in python-tx-tftp in trunk <roaksoax> are the same ones from the packaging <allenap> roaksoax: You didn't put "curl" before the URL ;) <roaksoax> allenap: yeah, curl http://localhost/MAAS/api/1.0/pxeconfig/?mac=12:34:56:78:90:ab&arch=i386&subarch=generic <roaksoax> gives the same <roaksoax> No Provided Arch <allenap> roaksoax: single quote it; the & is backgrounding the arch=... bit. <allenap> backgrounding the bit *before* rather. <roaksoax> allenap: that works <allenap> Okay, the problem is that there's a mismatch between the expectations of the TFTP server and what the pxeconfig view gives back. I'm still working on that. <roaksoax> alright <roaksoax> allenap: alright then, so I guess it is still not teasteable <roaksoax> allenap: though I'm just trying to enlist <roaksoax> allenap: and it doesn't work <allenap> roaksoax: I'm trying to fix it now. <roaksoax> allenap: ah ok thought it was deployment wise only not any pxe booting #maas 2012-08-24 <jtv> bigjools: fwiw I see the app server reporting upload_leases requests on the API â so at least the initial loop of the beat jobs is closed! <jtv> Hmmâ¦ looks like the request is being redirected though. <jtv> For authentication. <bigjools> oops <jtv> It's getting reported as success, but that may just be because the client is successfully told to bugger off â and I guess it just gives up. <jtv> It follows the redirect, gets the login page, andâ¦ done. <jtv> Hmm. Let me check the database. <jtv> Nope. Definitely not coming through. <rbasak> allenap: I just rebased my armhf patch series to today's trunk and have a conflict due to https://code.launchpad.net/~allenap/maas/new-tftp-layout/+merge/120182 <roaksoax> bigjools: group write means changing the permissions for path's where other package has been installed <roaksoax> bigjools: meaning we would be messing with the permissions of other applications <rbasak> allenap: not sure what the implications are for me right now. It feels like this hinders my progress since there's no replacement right now. Any ideas? <bigjools> rbasak: ok <bigjools> oops <bigjools> roaksoax: ok <allenap> rbasak: There are a few more branches on the way. See https://code.launchpad.net/maas/+activereviews for the ones I need to land. <roaksoax> bigjools: which I don't think/know is the right thing to do <roaksoax> bigjools: for that matter, sudoers might be a better approach <bigjools> roaksoax: ok, we need to make a code change for that <roaksoax> bigjools: but AFAIK sudoers only takes care of binaries, not files <bigjools> unless we can make celeryd run as root? <bigjools> too dangerous? <roaksoax> bigjools: I don't think the security team would want that <bigjools> ok <roaksoax> bigjools: another option could be to add the maas user to the daemon group <roaksoax> bigjools: i.e. add maas user to the bind group <roaksoax> that should cover it right? <bigjools> roaksoax: I don;t know how that affects things, can you explain? <roaksoax> bigjools: so if the maas user is in bind group, it would supposedly be able to access files that are for the bind group, right? <bigjools> oh what about dhcpd.conf? <roaksoax> bigjools: we should be able to do the same <roaksoax> bigjools: ig what I'm saying is right, then it should work <roaksoax> we'll have to test it out <bigjools> roaksoax: will it allow maas to restart the daemons? <bigjools> well we don't need to restart DNS other than at installation time <bigjools> since it uses an included config + rndc <roaksoax> bigjools: that it wont do. That would supposedly allow us to write in /etc/bind and /etc/dhcp/ <roaksoax> bigjools: for the daemons, we would need sudoers <bigjools> ok <bigjools> well it would still make my life easier to do the daemon group thing, it means a lot less code needs to change :) <roaksoax> indeed <roaksoax> so let me package tthis stuff first and then we can play with the group adding thing and sudoers <bigjools> check_call(['sudo', 'service', 'isc-dhcp-server', 'restart']) <bigjools> is what it does to restart <bigjools> awesome <roaksoax> bigjools: yeah, so we won't need to change anything <bigjools> ok, I need to go to bed RSN <bigjools> roaksoax: you rock :) <rbasak> allenap: there seem to be merge conflict markers in the diff in https://code.launchpad.net/~allenap/maas/pxe-intel-arch-config/+merge/121039. Is this intentional? <allenap> rbasak: Oh, I'll check that out. Thanks. <allenap> rbasak: They're real; I need to merge trunk. <rbasak> Oh, so this is how merge requests are supposed to work? I've not seen it before. <roaksoax> allenap: can you please check that http://paste.ubuntu.com/1164368/ has all your patches to python-tx-tftp <rbasak> Ah. "493 lines (+68/-315) 4 files modified (has conflicts)" <rbasak> I get it now :) <roaksoax> allenap: there might be one missin <allenap> jtv: Any chance of a +1 for https://code.launchpad.net/~allenap/maas/pxe-intel-arch-config/+merge/121039 <allenap> Please :) <jtv> coming <allenap> roaksoax: I'll take a look. * allenap can't remember how to use git <jtv> allenap: conflict. ( <jtv> Conflicts, even. :( <allenap> jtv: It's fixed and pushed, but Launchpad is being slow to catch up. <jtv> Yes, it's slow at the moment. <bigjools> allenap: bzr-git? :) <allenap> bigjools: I did try that, and I just didn't get on with it. <jtv> allenap: done <bigjools> yeah I think it's incomplete <allenap> jtv: Ta! <jtv> Not seeing why the API is redirecting the worker to the login page. If only piston didn't confuse Forbidden with Unauthorized... <bigjools> authenticated url type? <jtv> lawnmower fiscal epidermis? <jtv> bigjools: no idea what your question meant, sorry. <bigjools> is it unauth or auth api <jtv> Authenticated. * jtv goes to kitchen to make some hot toddy <bigjools> is the auth header getting added? <allenap> roaksoax: Full diff, I think: http://paste.ubuntu.com/1164399/ <roaksoax> allenap: ah, so there was things missing then <allenap> I have to go out for a bit, back in ~1h. <jtv> bigjools: it should be, since the request goes through the maas clientâ¦ any tips on how to verify? <bigjools> my brain shut down an hour ago <jtv> Eww toddy is vile without the honey <jtv> Oh seriously? My logs dir is empty? <roaksoax> bigjools: have you gusy hit an issue on PXE booting that causes an error with "Unable to locate configuration file" <roaksoax> bigjools: or is this due to the missing patch to python-tx-tftp <bigjools> roaksoax: could be to do with allenap's latest changes? <bigjools> otherwise did you run maas-import-pxe-files? <roaksoax> bigjools: i see this error since yesterday, so I'll wait for his changes to hit trunk <roaksoax> bigjools: yes I did run it <bigjools> ok I've not done a full boot for a few days * bigjools eod <bigjools> nn <jtv> allenap: have you seen this? https://bugs.launchpad.net/maas/+bug/1041158 <ubot5> Ubuntu bug 1041158 in MAAS "Worker not authenticating to API in upload_leases" [Critical,Triaged] <roaksoax> -D debian/maas-dhcp.config <roaksoax> -D debian/maas-dhcp.lintian-overrides <roaksoax> -D debian/maas-dhcp.postinst <roaksoax> -D debian/maas-dhcp.postrm <allenap> jtv: I saw that someone (you?) marked it critical, that's it. What's up? <jtv> allenap: it means that the worker can't send its leases back to the server. <allenap> jtv: Gah. I hope that's a simple fix :) I guess you're EOD nowish, and I'm away until Thursday after today. I'll try and look at it later this afternoon. <jtv> allenap: what's really fun is that as far as I can make out, the request isn't touching any code in piston's authentication.py. <jtv> Thanks. Technically I'm about EOD and a half. <allenap> jtv: It's POSTing to /nodegroups/master/ - no /api/... in front. <allenap> jtv: Indeed, you should be tucked up in bed with some cocoa. <jtv> Well I didn't have honey for the toddy, so I found some chocolate that's supposed to have honey in it. Is that good? <jtv> (It was needed. The concoction was horrible.) <allenap> jtv: Chocolate is almost always good for the mental state. <jtv> Mental yes. Physicalâ¦ Haven't been out at all today, so the sitting flesh isn't really supporting me any more. <jtv> Anyway, let me see about that URL <jtv> Yup, that's it! Missing prefix. <jtv> Just got a notice that the worker hadn't had a refresh from the server yet, so it wasn't sending DHCP. <jtv> Maybe that's something to do with the restart logic. <jtv> allenap: yay! Just a POST now. Not a lot of detail in the logs, but... <jtv> allenap: do you know off the top of your head how the API test can get at the netloc it's running its API at? <jtv> At least, I _think_ it runs real http on a real portâ¦ I hope it does. <allenap> jtv: settings.DEFAULT_MAAS_URL... and get_maas_facing_server_host() returns the hostname part of that. <allenap> Of course, that doesn't work outside of Django. <jtv> Yeah but does that apply to tests? <jtv> That's why I'm doing this in the API test, not in the worker test. <allenap> jtv: self.client.get(reverse(...), ...) or absolute_reverse(). <jtv> Hmmâ¦ it uses http://localhost/ <jtv> Wonder why it 404s when I feed that to the worker <allenap> jtv: I think self.client cheats. <jtv> Yes, I would expect it to. <allenap> Yay Django. <jtv> But I also thought there was a real service waiting for real http requests during the tests. <jtv> allenap: if you have timeâ¦ https://code.launchpad.net/~jtv/maas/bug-1041158/+merge/121207 <ubot5> Ubuntu bug 121207 in gcc-3.4 (Ubuntu) "[Feisty] Dangling symlink in amd64 libg2c0-dev package" [Undecided,Won't fix] <allenap> jtv: Sure :) <jtv> Thanks <jtv> ubot5 has quite an imagination. <ubot5> jtv: I am only a bot, please don't think I'm intelligent :) <jtv> Shut up. <jtv> allenap: oh dear... lots and lots of really strange-looking failures on a fresh branch. <allenap> Gah. <jtv> Mostly DNS stuff I think. <allenap> jtv: +1 for that mp. <jtv> Thanks. <jtv> And it looks like either start_up is now being called 3Ã where previously it was called once, or tests have been converted from FakeMethod to Mock and become accidentally stricter in the process. <allenap> jtv: Got time for a short review? https://code.launchpad.net/~allenap/maas/patch-mock-thing/+merge/121210 <jtv> Yes <allenap> Thanks. <allenap> Weird. <jtv> Done. <allenap> Thanks. <jtv> Well, trunk looks thoroughly broken & I don't see a clear single reason <jtv> Or does it? Maybe it's just my fresh branch that's broken. <jtv> Yup. It's my branch. Maybe I shouldn't have named it all-you-zombies. <allenap> Heh <allenap> jtv: Do you ever use `lsof +D` btw? It is remarkably useful for finding still running stuff that's causing weird failures. <allenap> Well, `lsof +D $directory`. <jtv> Oh, no, I don't use the whole program much actually. <jtv> And usually I just grep my way around the output of such tools. <allenap> jtv: I guess I'm interested to know how other people do this stuff. lsof is the best thing I've found for this, but fuser can do similar things. <jtv> There's so much of this out there that I prefer to remember just a few simple things. <rbasak> lsof has always confused me. I use it as a last resort, usually combined with grep <jtv> Tools like âcutâ can also help query and manipulate structured output uniformly. <allenap> roaksoax: I've just landed the last of my branches for this week. Any chance of a new package? * allenap has to go now, have a good weekend everyone. <jtv> nn allenap! <roaksoax> allenap: there's a newer precise version <roaksoax> jtv: you know anything about the tftp server? <jtv> roaksoax: a bit <roaksoax> jtv: when trying to PXE boot, what happens if no PXE IP/MAC is found <jtv> That's not really a question of the tftp server â by convention, the pxe client loads a config named âdefaultâ in that situation. <roaksoax> jtv: wheres is that default ? where is it being handled? <roaksoax> jtv: i keep getting an "unable to locate configuration file" <jtv> It's dynamically generated by the tftp server. <jtv> But that's probably not the issue here. <jtv> The problem would seem to be in matching the path. <roaksoax> jtv: right, (i get this on pserv.log: 2012-08-24 13:03:32-0400 [TFTP (UDP)] Datagram received from ('575.979.1648', 49162): <RRQDatagram(filename=pxelinux.cfg/default, mode=octet, options={'tsize': '0', 'blksize': '1408'})> <roaksoax> ) <jtv> That means your DHCP server isn't configured right. <roaksoax> jtv: my DHCP is right <roaksoax> jtv: i have been working with it <roaksoax> jtv: pre cobblerless MAAS <jtv> But everything was very different back then. <roaksoax> jtv: right, but DHCP only needs to tell where the bootp is for it to PXE boot <roaksoax> jtv: it is an external DHCP <roaksoax> jtv: this is on a virtual environment though <jtv> Is this i386? <roaksoax> jtv: its a VM <jtv> An i386 VM? <roaksoax> can't recall TBH <roaksoax> it is my local dev environemtn <jtv> So either i386 or amd64 then? <roaksoax> that's been working since orchestra <roaksoax> yep <jtv> OK <jtv> Do you see any sign in the TFTP logs of pxelinux.0 being requested? <roaksoax> jtv: where is that particular log stored? the only that has anything releated is pserv.log <jtv> Because from what I heard, there's a weirdness where that file's directory effectively becomes the root for the session. <jtv> That should be the one, yes <roaksoax> jtv: http://paste.ubuntu.com/1164794/ <jtv> That's taking a while to load. <jtv> May be beacuse I'm doing a big fsck. <jtv> Was there no mention of pxelinux.0 in that log? It's possible because plain files are served in a different way from config files. <roaksoax> jtv: the only mention is: [TFTP (UDP)] Datagram received from ('575.979.1648', 1024): <RRQDatagram(filename=pxelinux.0, mode=octet, options={'blksize': '1432', 'tsize': '0'})> <jtv> That makes it harder to find the information we need. <jtv> Is there any helpful logging on the client side? <jtv> Oh wait,I see now <jtv> Sorry; it's late here and I'm not well. <jtv> Having a bit of trouble reading from the screen. <jtv> Well this tells us that the DHCP setup is definitely not right. <roaksoax> jtv: hehe no worries <roaksoax> jtv: the DHCP server is libvirt <jtv> And it's not set up to point clients to the right TFTP path. <jtv> The right server, yes. <roaksoax> jtv: "<bootp file='pxelinux.0' server='575.979.1648' />" <jtv> But not the right path. <jtv> Yes. <jtv> That's wrong. <roaksoax> jtv: what's the right path? <jtv> We use maas/<arch>/generic/pxelinux.0 <roaksoax> jtv: right, but in a DHCP you can't tell what patch to use based on the arch right? <jtv> You can, but it's tricky. <roaksoax> jtv: ah, so why are we doing that then <jtv> It's what we do in a MAAS-generated config. <roaksoax> jtv: right, but when we are not using MAAS DHCP <roaksoax> jtv: then that should not happen <jtv> But as long as you've got a single-architecture setup, you can just use the path I gave you â with either i386 or amd64 <jtv> (The paths are changing, but I don't think they've changed yet) <roaksoax> jtv: right, but that defeats the purpose of PXE booting doesn it? <jtv> Not really. The purpose of PXE booting is to give us control of a machine across power cycles. <roaksoax> jtv: right, so in a mixed network, with external DHCP., we are in trouble <jtv> Now, <roaksoax> jtv: on the case of an upgrade, we are screwed <jtv> the i386 image will work just fine for amd64 machines. <jtv> An upgrade? <roaksoax> jtv: so, we have a maas server, we upgrade precise version to latests, we don't modify external DHCP <roaksoax> then we have a broken maas infrastrcuture <jtv> Yes, so it seems. <roaksoax> that makes administrator manually modify their DHCP servers <jtv> Yes, it's a manual step if MAAS doesn't manage DHCP. <roaksoax> jtv: rigt, which defeats the purpose of everything <roaksoax> jtv: i think there should be some defaults to continue to use the older path <roaksoax> and default to i386 <roaksoax> for these cases at least <jtv> I suspect you could work around that by installing pxelinux on the server. <roaksoax> right, but we won't have the systems available would we? <jtv> Hmm that fixes the pxelinux.0 problem, but not the config one. <roaksoax> exactly <jtv> You already have pxelinux-common installed, I suspect. <roaksoax> yep <roaksoax> IMHO, this is a regressio <jtv> Gavin was working on this, but he has eow'ed. <roaksoax> yeah, oh well <jtv> And for me it's technically saturday now, so I won't be around for long enough to fix this tonight. <roaksoax> no worries <roaksoax> i'll try to look into it if I find the time after i finish the stuff i need to get done <jtv> Would a workaround help? <jtv> Temporary one? <rbasak> Are you guys talking about a regression for precise->precise-updates, or precise->quantal? <roaksoax> jtv: heh, now I get a permission denied to obtain the file :) <jtv> What did you change? <roaksoax> jtv: i changed the pxelinux path <jtv> rbasak: I think we missed the 12.04.1 window, so I think the most urgent issue would be the latter. But I'm not too sure. <jtv> roaksoax: what did you change it to? <rbasak> Hmm, ok <roaksoax> jtv: <bootp file='maas/i386/generic/pxelinux.0' server='575.979.1648' /> <jtv> Then what's biting you now, I think, is the problem that our patch for the tftp server is not in the package. <roaksoax> jtv: probably. I have to review that by EOD too <roaksoax> jtv: alright then. Thanks for the help :) <jtv> Waitwaitwait <jtv> I don't think you answered my question: would a workaround help? Temporary one? <jtv> Or would it be a waste of time? <roaksoax> jtv: to older way pxelinux.0 was located? I guess it would <roaksoax> jtv: I think sabdfl wanted to test over the weekend, but we can point out to the change in the DHCP server <jtv> Well he said he was quite keen to, so hell yeah he wants to test over the weekend! <jtv> I just wonder if this is what Gavin was doing. Let me look. <roaksoax> jtv: ok :) btw.. if you can point me out to the branch where the permission thing was fixed for python-tx-tftp would be great too <jtv> Ouch. I don't know that. I only heard it talked about. <jtv> Don't even know if it's on launhpad or github. <roaksoax> jtv: hehe no worries, I'll look it up * roaksoax off to lunch before he gets cranky <jtv> OK. <roaksoax> jtv: thanks for the help though <jtv> I have something in mind for the config files, making use of something Gavin landed tonight. <jtv> Oh dear. Where do we match âdefaultâ config at all? <jtv> I remember now. We generated it as part of the filesystem tree when installing a new image. <jtv> But not now, I think... <jtv> roaksoax: having serious system problems now, not sure why. But I have a branch that you might want to try. It may solve at least part of the problem. <roaksoax> jtv: got the access denied issue figured out.. python-tx-tftp was with incomplete patches apparently <jtv> Hmm <roaksoax> but it seems that i just found another issue :) <roaksoax> permissions wrongly set for commissioning directory <jtv> I may drop out of the conversation at any moment. <jtv> Commissioning directory? <jtv> You mean in /var/lib/tftpboot/...? <roaksoax> jtv: /var/lib/tftpboot/maas/.../commissioning <roaksoax> jtv: yeah <jtv> We fixed that a few weeks back. <jtv> Or maybe this week? <jtv> Not very long ago. <roaksoax> jtv: uhmmm upgrading didn't work right then <roaksoax> jtv: now it doesn't enlist <jtv> Did you get past the problem of not finding the default pxe config somehow? <roaksoax> jtv: yeah <roaksoax> just edited the path to maas/pxelinux.0 <roaksoax> jtv: and now : NameError: name 'preseed_data' is not defined at line 14 column 3 in file /usr/share/maas/preseeds/generic at line 87 column 3 in file /usr/share/maas/preseeds/preseed_master <jtv> roaksoax: back after some system troubleâ¦ how did you get around the pxe-config problem? <roaksoax> jtv: <bootp file='maas/pxelinux.0' server='575.979.1648' /> <jtv> And then the machines booted into enlistment? <roaksoax> jtv: they boot into the commissioning environment that does the enlistment <roaksoax> jtv: but there's an error on the preseed <roaksoax> NameError: name 'preseed_data' is not defined at line 14 column 3 in file /usr/share/maas/preseeds/generic at line 87 column 3 in file /usr/share/maas/preseeds/preseed_master <jtv> Scott may know. <roaksoax> smoser: ^^ <jtv> roaksoax: I'm crashing. I've got a review up for a compatibility change that would solve your previous problem, but I'm not in a state where I can judge whether it's a good idea. I'll have to call it a night! <smoser> oh fool. <smoser> foo <smoser> not fool <jtv> food? <smoser> where is this? <smoser> trunk ? <roaksoax> jtv: thanks a lot! it used to be under maas/<arch>/etc/etc/pxelinux.0 now it is under maas/pxelinux.0 so should be easier <roaksoax> smoser: trunk <roaksoax> smoser: packaging up the latest trunk <jtv> roaksoax: the branch I have up here also supports the classic pxelinux.cfg/*: https://code.launchpad.net/~jtv/maas/bug-1041318/+merge/121266 <ubot5> Ubuntu bug 121266 in openoffice.org (Ubuntu) "OpenOffice does not start: abnormal early exit ..." [Undecided,Invalid] <jtv> Shut up, bot. <roaksoax> jtv: cool I'll take a look <smoser> i dont know from the to po fmy hhead. <roaksoax> smoser: ok ;) <allenap> roaksoax: Do you have some background on bug 1041327? <ubot5> Launchpad bug 1041327 in MAAS "Where's the âdefaultâ PXE config?" [Critical,Triaged] https://launchpad.net/bugs/1041327 <roaksoax> allenap im guessing is the fact that in order to use the tftp we have to tell the external dhcp server that pxelinux.0 is in maas/pxelinux.0 <allenap> roaksoax: jtv mentioned that you were having problems with that, in a merge proposal. Is that because the boot filename cannot be set on your DHCP server? <roaksoax> allenap so on upgrades for those who have external dhcp maas is "broken" <roaksoax> becauae if you upgrade maas magically tftp fails <allenap> roaksoax: Ah, is this only pertinent to upgrades? <roaksoax> yrs <allenap> Righty ho. In https://code.launchpad.net/~jtv/maas/bug-1041318/+merge/121266 I ponder if we shouldn't just get rid of the maas/ prefix completely. <ubot5> Ubuntu bug 121266 in openoffice.org (Ubuntu) "OpenOffice does not start: abnormal early exit ..." [Undecided,Invalid] <allenap> ubot5: Your regex is wrong. <roaksoax> allenap leaving it there might be benefitial if we have Nother infrastructure in pla e <roaksoax> the only problem i see is that since pxelinux.0 that maas is using chanves administrators will see this as broken <roaksoax> becauze they would need yo update the dhcp server to tsll the new location <roaksoax> however this could so be a regression <roaksoax> because an upgrade and path location haz changed <roaksoax> so if old pxelinux.0 is left Nd dchp server not chsnged then cinfig file iz not found <roaksoax> on new jnsls we have to tell the admin tha oxelinux.9 for maas has changrd location but in uogrades we cant just simply change and expect admins will figure out wjat was wrong <roaksoax> so it should be backwards comoatible <roaksoax> allrnap unless we tell tctp that root is /var/lib/tftpboot/maas <roaksoax> dahhh that shiuld cover it <roaksoax> so no need for code chsnges rught? <roaksoax> only config <allenap> roaksoax: I'm way too tired to understand all that right now! I think it may be best if you email the list, as I'm away until Thursday next week too. <allenap> roaksoax: Have a good weekend, thanks for putting up with us upstreamers :) <roaksoax> allenap will do have a good week <roaksoax> hehe no worries <roaksoax> glad to had the chance to work with u guys #maas 2012-08-27 <Vampy> does any have a guide or suggestion for setting up a MAAS server that isnt DHCP, but still run PXE? <dannf> Vampy: i.e. using a separate dhcp server? that works fine as long as you set the "next-server" option to be your maas server <Vampy> dannf, would the idea of using 2 nics when the maas is behid a dhcp enabled router be wiser? the router isnt running drt so i'm unable to edit for next-server <dannf> Vampy: yeah, putting your MAAS on its own subnet probably makes sense there <Vampy> so running the eth0 as the internet accessable nic and eth1 as a dhcp for the switch and nodes with a bridge from eth0 to eth1 <dannf> not sure you'd want to bridge it <dannf> maybe masquerade the eth1 network
{'channel': 'maas', 'month': 8}