| roaksoax | bigjools: o/ | 01:36 |
|---|---|---|
| bigjools | hi roaksoax | 01:36 |
| bigjools | just starting to look at your branch | 01:36 |
| bigjools | roaksoax: did you mix up two branches? | 01:38 |
| bigjools | I see the test fixes with the chmod changes | 01:38 |
| roaksoax | bigjools: yeah I commited the chmod changes on top of the test fixes which is another merge | 01:39 |
| bigjools | roaksoax: your chmod changes aren't enough I think | 01:39 |
| roaksoax | bigjools: just I just thought if you accept the test fixes first, that should not cause any problems with the chmod changes | 01:39 |
| bigjools | because it was a directory permission problem | 01:39 |
| roaksoax | bigjools: I tested both with successfuly results | 01:40 |
| bigjools | huh reallyu | 01:40 |
| roaksoax | bigjools: so the chmod in src/provisioningserver/pxe/install_image.py takes care of the directory | 01:41 |
| bigjools | roaksoax: I would have expected a fix in make_destination() | 01:41 |
| bigjools | because it was the commissioning/ dir that was 600 | 01:41 |
| roaksoax | bigjools: right, but that happens on the rename, so we might as well do that after renaming | 01:42 |
| bigjools | roaksoax: I don't understand how renaming fixes the directory permission - it clearly works if you tested it ok, but I am missing something | 01:43 |
| roaksoax | bigjools: renaming doesn't fix it | 01:45 |
| roaksoax | bigjools: when it renames is when the permissions get screwed | 01:46 |
| bigjools | yep | 01:46 |
| roaksoax | bigjools: so that's why I thought the chmod should go right after the rename | 01:46 |
| bigjools | but I thought it renamed the file, not the dir | 01:46 |
| roaksoax | bigjools: a right, but that critical section seems to be the part of directory creation | 01:48 |
| bigjools | seems so.... humph | 01:48 |
| bigjools | I am getting test failures, can't tell if it's your changes or not, give me a few minutes | 01:49 |
| roaksoax | k | 01:49 |
| roaksoax | bigjools: right, there maas-import-pxe-files errors | 01:51 |
| * roaksoax brbr | 01:51 | |
| bigjools | roaksoax: will leave you to fix that then :) | 01:55 |
| bigjools | shout if you need help | 01:56 |
| jtv1 | Test suite still completely broken. :( | 02:02 |
| jtv1 | bigjools, roaksoax: this is not a good time to land changes -- we're not passing tests. It's what kept me from fixing the permissions problem yesterday. | 02:04 |
| bigjools | hi jtv1 | 02:04 |
| bigjools | I didn;t know things were broken still | 02:04 |
| jtv1 | Eleven failures, one error. | 02:05 |
| bigjools | I am running a make check on trunk now | 02:05 |
| jtv1 | Here's the MP that broke it: https://code.launchpad.net/~andreserl/maas/maas_tftppath_lp1042877/+merge/121676 | 02:05 |
| bigjools | oh that - roaksoax's branch is trying to fix it | 02:06 |
| bigjools | roaksoax: need tests: https://code.launchpad.net/~andreserl/maas/maas_set_correct_file_permissions/+merge/121974 | 02:07 |
| jtv1 | Why is the /maas prefix incorrect in the first place? AFAICT it's correct, but optional. | 02:07 |
| bigjools | nothing would boot | 02:07 |
| bigjools | the paths were inconsistent compared to the actual location of pxelinux.0 | 02:08 |
| bigjools | also | 02:08 |
| bigjools | it was a problem for upgrading from previous installations | 02:08 |
| bigjools | (using Cobbler) | 02:09 |
| bigjools | since /maas didn't exist | 02:09 |
| bigjools | and we can't rely on being able to change the dhcp config | 02:09 |
| jtv1 | The latter I know -- I was the one who made it optional. But didn't Gavin move the location of pxelinux.0 to maas/ ? | 02:11 |
| jtv1 | By the way, small mistake in that branch. I commented on the MP. | 02:11 |
| jtv1 | At least I think it's a mistake! | 02:12 |
| bigjools | the critical section is merely a comment so it doesn't matter as such | 02:13 |
| bigjools | jtv1: he's fixed a load of the errors but not all | 02:13 |
| bigjools | (in the other branch) | 02:13 |
| jtv1 | "The critical section is merely a comment"!? | 02:13 |
| jtv1 | Like that. | 02:13 |
| jtv1 | The critical section ends when the new directory is in place *and readable*. | 02:14 |
| bigjools | no | 02:14 |
| bigjools | when it's in place | 02:14 |
| jtv1 | If that directory is not readable, it's no use to anyone. | 02:14 |
| bigjools | that doesn't make it part of the critical section | 02:15 |
| bigjools | since only one user is *changing* it | 02:15 |
| jtv1 | The critical section is effectively the time between the moment we can no longer use the old directory, and the time we can start using the new one instead. This approach postpones that, for no reason whatsoever. | 02:16 |
| bigjools | true, it would be better on the original dir | 02:17 |
| jtv1 | Right. | 02:17 |
| jtv1 | There's just no reason to do it the wrong way -- except the name is easier to spell, which can be solved with a variable. | 02:17 |
| bigjools | jtv1: can I leave you to help roaksoax please, I've got a million other things to sort out | 02:18 |
| bigjools | his branch still has failures | 02:18 |
| jtv1 | I do have a doctor to see. :/ | 02:18 |
| === jtv1 is now known as jtv | ||
| === jam1 is now known as jam | ||
| jtv | allenap, bigjools, Daviey, rbasak: here's a new suggestion for prefix-less PXE layout on TFTP. Saves us the bootloader downloads, resolves the compatibility problem, removes the prefix, usurps /var/lib/tftpboot/pxelinux.cfg for our own use. http://paste.ubuntu.com/1175480/ | 09:27 |
| jtv | Oh, and: moves us towards a solution for the amd64/i386 problem, I think. | 09:27 |
| bigjools | jtv: jfdi! | 09:31 |
| allenap | jtv: Why are the arch specific bits inside pxelinux.cfg/? | 09:31 |
| allenap | jtv: Also, the i386/amd64 problem should be fixed already, pending QA, unless this is something else. | 09:31 |
| allenap | jtv: Want to talk about it? | 09:34 |
| jtv | allenap: Yes please. | 09:35 |
| allenap | jtv: https://plus.google.com/hangouts/_/0d5426deed76294d0b13f6d467e9d286b7a1d52a?authuser=0&hl=en-GB | 09:35 |
| allenap | rbasak: Can we delay by 20 minutes? | 09:53 |
| rbasak | sure | 09:53 |
| jtv | Daviey: just wanted to make absolutely sure... if we PXE-boot /pxelinux.0, using a config from /pxelinux.cfg, we can still load kernel/initrd from /maas, right? We're not forced to load from within /pxelinux.cfg, right? | 10:18 |
| Daviey | yeah.. | 10:43 |
| Daviey | jtv: i don't see why you couldn't? Which makes me concerned i'm missunderstanding the question | 10:44 |
| jtv | No, just checking up on the details of the problem where once you're booting from a directory, PXE can't seem to reference TFTP files from outside that directory. | 10:44 |
| jtv | This was a big issue some time ago. | 10:45 |
| Daviey | jtv: I think the issue was more, the -secure option.. which did better chrooting.. and enforiced ownership.. no? | 11:17 |
| jtv | No, not related to that. | 11:17 |
| jtv | Daviey: But we were told at one point that we couldn't just pass absolute paths to the tftp server; it had to be relative to either (and I'm trying to verify which it was) the directory with pxelinux.0 in it, or the pxelinux.cfg directory. | 11:18 |
| Daviey | jtv: I'm not aware of such a limitation, i'm sure i've used full paths (from tftproot) all the time. | 11:23 |
| jtv | ! | 11:24 |
| jtv | Even for kernel & initrd? | 11:24 |
| jtv | Now I'm just completely confused. | 11:24 |
| Daviey | jtv: it might be better to JFDI and prove me wrong :) | 11:25 |
| Daviey | rbasak: Do you have thoughts ^^? | 11:25 |
| jtv | We spent so much time on questions like "once you're in an i386 config file, how do you get the amd64 kernel/initrd if they're in a different directory?" | 11:25 |
| Daviey | jtv: why would you be in the i386 file? | 11:25 |
| jtv | Daviey: it'd be hard for me to prove myself wrong. Which I need to be able to do to make sensible decisions. | 11:25 |
| jtv | You'd be in an i386 config file if you were a netbooting PXE client. | 11:26 |
| Daviey | then why would you jump to amd64? | 11:26 |
| jtv | Because you might actually be amd64. | 11:26 |
| Daviey | I think i am being dumb. | 11:26 |
| jtv | Well think about enlistment. | 11:26 |
| jtv | Server doesn't know who or what you are. | 11:26 |
| jtv | You request a boot config; the server gives you i386. | 11:27 |
| Daviey | jtv: i thought we were using Ifcpu.c32 / Ifcpu64.c32 now? | 11:27 |
| jtv | Ah no, enlistment is OK. | 11:27 |
| jtv | Yes, we are using that now. | 11:27 |
| jtv | But like I said, we spent a lot of time arriving at that. | 11:27 |
| Daviey | ah | 11:27 |
| jtv | The real problem came when you had to install the right architecture despite perhaps having been served the wrong architecture for PXE. | 11:28 |
| jtv | Anyway, we had to do that, and some other acrobatics, because we had been told that once you load pxelinux.0/pxelinux.cfg, you're stuck in the location you got those, TFTP-wise. | 11:28 |
| jtv | For the rest of that boot, obviously. | 11:29 |
| jtv | Not forever. | 11:29 |
| rbasak | Daviey, jtv: I'd like to verify this by looking at the U-Boot source and also checking behaviour in U-Boot. The behaviour in U-Boot may well be different than pxelinux itself here. | 11:43 |
| jtv | Ahh that could be the missing piece of the puzzle. | 11:43 |
| jtv | Would be most grateful if you could check! | 11:43 |
| * rbasak looks | 11:44 | |
| Daviey | ahh, yes.. could be | 11:49 |
| rbasak | Daviey, jtv: right. I've looked at the logic | 11:52 |
| rbasak | It will be relative unless the path supplied starts with / | 11:53 |
| jtv | (God, the staggering incompetence of some people... adding a "North" arrow to a map that duly points up... but actually orienting the map in some radically different way. Leaving the "Public Company Limited" suffix in the name of a landmark office building, when there's not enough room to write it. Transliterating street names incorrectly. Is this company testing my motivation to come see them?) | 11:53 |
| jtv | rbasak: so then there's no way at all in which we're stuck in a directory and we could have used absolute paths all the time!? | 11:53 |
| rbasak | If it starts with /, then the name is left as-is and requested from the tftp server | 11:53 |
| Daviey | jtv: where did you hear about this limitation ? | 11:54 |
| rbasak | If it doesn't start with a /, then the name pxelinux.0 was fetched from is truncated to its last / and the name appended | 11:54 |
| rbasak | I don't think that tftp has a notion of directories at all. Everything is just a name | 11:54 |
| Daviey | right, that is the same as x86. | 11:54 |
| rbasak | So how the leading / is interpreted is up to the tftp server in use | 11:54 |
| jtv | (The one we use, in the upstream version, just chokes I think) | 11:55 |
| rbasak | So it is still a bit limited. If you serve "maas/pxelinux.0" for example, I don't think it's possible to get U-Boot to fetch "kernel". It'd have to be "/kernel" or "maas/kernel". | 11:55 |
| rbasak | I am basing this from the current linaro U-Boot source and current highbank behaviour only | 11:56 |
| rbasak | If the behaviour was different in the past, I won't see it | 11:56 |
| jtv | So maybe this limitation does exist, in a way -- a tftp server doesn't necessarily support absolute paths. We had trouble with that. | 11:56 |
| * rbasak goes looking for the VCS tree | 11:56 | |
| rbasak | jtv: agreed. I would be very careful in the assumptions made here, since TFTP itself doesn't define anything. | 11:57 |
| rbasak | (I don't think) | 11:57 |
| jtv | Now, if we have some sort of equivalent of "current directory" set, we do know that it's going to be the same directory we found pxelinux.0 in then? | 11:57 |
| rbasak | Yes. This is how U-Boot was engineered from the start. I think this is based on pxelinux.0's behaviour. | 11:58 |
| rbasak | Look for robher on here. He's not online now but sometimes is. He wrote it. | 11:59 |
| jtv | So if we start out with pxelinux.0 as the boot-loader filename, in /, and read config from pxelinux.cfg/* in root, then we can continue using our normal filenames. | 11:59 |
| rbasak | If I understand you correctly then yes, I think so. Can you just show me the structure again? | 12:00 |
| jtv | Gah. Keyboard layout switching is completely demented with this USB keyboard attached. :( | 12:01 |
| rbasak | Ah it wasn't robher, it was Jason Hobbs who wrote it (also Calxeda) | 12:01 |
| jtv | Well "the" structure is the question. | 12:02 |
| jtv | What I'm currently implementing is: | 12:02 |
| rbasak | And the original code has the same special case leading '/' handling | 12:02 |
| rbasak | At least the original code that went into linaro trunk. So I think we're ok relying on that. | 12:02 |
| jtv | /pxelinux.0 | 12:02 |
| jtv | /pxelinux.cfg/default | 12:02 |
| jtv | /i386/generic/precise/commissioning/initrd.gz | 12:02 |
| jtv | etc. | 12:02 |
| jtv | (I'm spelling out the leading slashes here for illustration; we don't actually use them.) | 12:03 |
| rbasak | If the pxelinux.cfg files then use "kernel i386/generic/precise/..." etc, then I think that'll work | 12:06 |
| rbasak | (I'd keep those paths relative to avoid any issues) | 12:06 |
| jtv | Ahhhh figured out my map. The key was the road that crossed the water, with the arrow to the bridge pointing _away_ from the water. The big wobbly curvy waterway it shows is not in fact the river. It's a canal, and according to Google, nicely straight. | 12:06 |
| rbasak | Also probably best to keep the dhcpd.conf filename "pxelinux.0" relative (to nothing) too. | 12:06 |
| jtv | Yes, it should all set up like that at the moment. | 12:07 |
| jtv | Just wanted to be sure that the naming after loading would still be relative to the root in our case, and not to pxelinux.cfg. | 12:07 |
| rbasak | Yes, that's right. It's relative to the location of pxelinux.0, not of pxelinux.cfg. | 12:08 |
| jtv | Thanks for the help! It's frightening to work in the dark sometimes. | 12:08 |
| rbasak | (pxelinux.cfg needs to be in the same location as where pxelinux.0 is) | 12:08 |
| rbasak | No problem. I hope I've been accurate! | 12:08 |
| jtv | Certainly more so than whoever made this map. | 12:09 |
| jtv | allenap: any chance I could get you to review a few branches for me? They're wildly disparate -- one is near-trivial and the other is huge. | 12:12 |
| jtv | The trivial one is: https://code.launchpad.net/~jtv/maas/use-maasserver-testcase/+merge/122002 | 12:12 |
| jtv | The huge one is: https://code.launchpad.net/~jtv/maas/bug-1042877/+merge/122049 | 12:20 |
| ubot5 | Ubuntu bug 111956 in Launchpad itself "duplicate for #122049 Cannot search for identifier containing underscores" [Low,Triaged] | 12:20 |
| allenap | jtv: Sure, no worries. | 12:23 |
| jtv | Thanks | 12:23 |
| bjf | i'm currently using orchestra to provision bare metal systems as well as VMs (using koan). am i able to replace orchestra with maas for all that? | 15:26 |
| === matsubara is now known as matsubara-lunch | ||
| === frankban_ is now known as frankban | ||
| === matsubara-lunch is now known as matsubara | ||
| smoser | roaksoax, how can i create a maas super user without typing a password ? | 17:26 |
| roaksoax | smoser: no diea | 17:27 |
| smoser | anyone ? | 17:27 |
| smoser | hey roaksoax | 17:33 |
| smoser | i boot a node. and enlist it | 17:34 |
| smoser | then say "commission" | 17:34 |
| smoser | all well and good | 17:34 |
| smoser | then i turn it on again | 17:34 |
| smoser | what is it supposed to do? | 17:34 |
| bjf | i'm currently using orchestra to provision bare metal systems as well as VMs (using koan). am i able to replace orchestra with maas for all that? | 17:38 |
| smoser | bjf, yeah, thats the goal. | 17:40 |
| bjf | smoser: how close are we today? can i provision both bare-metal as well as VMs today? | 17:40 |
| smoser | i would say yes to both. | 17:41 |
| smoser | you'll have to manage your virtual machines yourself | 17:41 |
| smoser | and a machine is basically identified by its "eth0 MAC address" | 17:41 |
| smoser | so you have to keep that consistent | 17:41 |
| bjf | smoser: i'm doing kernel testing with jenkins jobs and orchestra + koan right now. that's a lot of VMs being dynamically created and destroyed | 17:42 |
| smoser | well, mi could be wrong here. | 17:43 |
| smoser | but baically, maas is going to identify each new vm as a new system. | 17:43 |
| smoser | and that system will have to go through enlistment and commissioning | 17:44 |
| smoser | its possible that you could use the api to populate images and absically pass it through ocmmissioning before nhand. | 17:44 |
| roaksoax | smoser: hold on, you enlist and then you "Accept and Commission" | 17:44 |
| smoser | and then also to delete it when youre done | 17:44 |
| roaksoax | smoser: it enlists and turns off | 17:44 |
| smoser | roaksoax, yes, and then i commission | 17:44 |
| smoser | that is all well and good | 17:44 |
| smoser | but what happens if i turn it on after that | 17:44 |
| roaksoax | smoser: it fails to PXE | 17:44 |
| smoser | thtas not my experience in precise | 17:44 |
| bjf | ok, can i do enlistment and commissioning from the command line? do you have a cli or do i need to write a tool myself? | 17:45 |
| roaksoax | smoser: really? I saw soemthing that was trying to PXE boot from a poweroff like profile or something likethat but it failed due to not being found | 17:45 |
| smoser | you'd have to write a maas api client for that. | 17:45 |
| smoser | bjf, | 17:45 |
| roaksoax | smoser: i just spotted that yesterday so didn't really investigate it yet | 17:45 |
| bjf | smoser: and can i write that in python? | 17:45 |
| smoser | bjf, i dont know how good you are with python :) | 17:46 |
| smoser | but yes, you could do it in python | 17:47 |
| bjf | smoser: heh | 17:47 |
| bjf | smoser: i should have asked if python is a supported language for such work :-) | 17:47 |
| smoser | bjf, well its a web service api | 17:47 |
| smoser | and you'd have to write the client (no easily available library for you at the moment) | 17:47 |
| smoser | now... | 17:48 |
| bjf | smoser: one that you have documented? | 17:48 |
| smoser | if you *wanted* to write a maas cli that would make people happy. | 17:48 |
| bjf | lol | 17:48 |
| smoser | bjf, i dont document anything, ever. | 17:48 |
| smoser | and honestly i dont think the maas api is terribly well documented (but i could be wrong) but there are examples of using it. | 17:48 |
| smoser | juju uses it, and i had started a client | 17:48 |
| bjf | smoser: ok, some examples would be good enough | 17:49 |
| smoser | which i can point you at. | 17:49 |
| bjf | cool | 17:49 |
| bjf | ok, that's all for now .. i'll be back | 17:49 |
| smoser | https://code.launchpad.net/~smoser/maas/maas-cli/+merge/101440 | 17:49 |
| smoser | roaksoax, its confusing | 17:54 |
| smoser | i think its actually doing an install | 17:54 |
| smoser | acutally pretty certain it is | 17:54 |
| roaksoax | smoser: ok, I'll have a look | 17:55 |
| roaksoax | maybe so | 17:55 |
| smoser | it says "Installing the base system" | 17:55 |
| smoser | :) | 17:55 |
| roaksoax | smoser: what MAAS are you using? | 17:55 |
| smoser | precise at the moment. | 17:55 |
| roaksoax | smoser: from PPA? | 17:55 |
| smoser | http://pad.daviey.com/maas-ephemeral-image-test | 17:58 |
| smoser | no. from precise updates or whatever is there. | 17:58 |
| smoser | this was in an effort to validate the dialy ephemeral image that i built yesterday. | 17:58 |
| smoser | and see that link, thats how i did it. | 17:59 |
| roaksoax | ok | 18:05 |
| smoser | roaksoax, i'm gonna walk the same thing on quantal now. | 18:12 |
| smoser | its kind of a shortcut on the vdenv | 18:12 |
| roaksoax | smoser: note that we should be uploading cobblerless maas very soon though | 18:13 |
| smoser | sure. and osme of that stuff is cobbler specific. but much is not. | 18:14 |
| smoser | roaksoax, on quantal right now i do maas-import-isos | 18:23 |
| smoser | i see | 18:23 |
| smoser | Unknown command: 'install_pxe_image' | 18:23 |
| smoser | am i not supposed to run that ocmmand? | 18:23 |
| roaksoax | smoser: yeah that's find | 18:29 |
| roaksoax | fine | 18:29 |
| roaksoax | smoser: it is and old maas version | 18:29 |
| smoser | roaksoax, wait a minute. | 18:55 |
| smoser | i'm booting the installer | 18:55 |
| smoser | in enlistment | 18:55 |
| smoser | on quantal | 18:56 |
| smoser | why? | 18:56 |
| roaksoax | smoser: becuase cobblerless maas is not yet in quantal | 18:57 |
| roaksoax | smoser: there | 18:57 |
| roaksoax | smoser: there's was a few issues that needed to be addresses before I can upload it otherwise we would have had a broken MAAS | 18:57 |
| roaksoax | i'm hoping to have an upload by tomorrow | 18:57 |
| smoser | but i changed the cobbler path | 18:58 |
| smoser | to use ephemeral enlistment | 18:59 |
| smoser | and the other path | 18:59 |
| smoser | roaksoax, oh. i see. quantal is still as of July 17 | 19:01 |
| smoser | wow | 19:01 |
| smoser | thats old | 19:02 |
| smoser | roaksoax, could you tell me what you were doing yesterday that caused you to know about my ephemeral image mishap? | 19:03 |
| roaksoax | smoser: trying to enlist | 19:18 |
| roaksoax | with the new maas of course | 19:19 |
| roaksoax | ppa:maas-maintainers/testing | 19:19 |
| roaksoax | precise | 19:19 |
| smoser | roaksoax, i'm getting a debconf change prompt | 19:21 |
| smoser | on upgrade in quantal from quantal to daily ppa | 19:22 |
| roaksoax | smoser: what's it about? | 19:22 |
| smoser | http://paste.ubuntu.com/1176499/ | 19:22 |
| smoser | just did the install on quantal, then added daily ppa | 19:22 |
| smoser | and upgraded | 19:23 |
| smoser | also now pserv i prompting me | 19:23 |
| roaksoax | smoser: yeah | 19:23 |
| roaksoax | smoser: do that | 19:23 |
| smoser | well, of course yes. | 19:23 |
| roaksoax | and it will re=generate passwords and stiff | 19:23 |
| smoser | i'm just saying its a bug | 19:23 |
| smoser | it should not prompt me. i did not change that file. | 19:23 |
| roaksoax | smoser: no you didn't, but upstream did | 19:23 |
| smoser | and all users would hit that. | 19:23 |
| roaksoax | smoser: and the package did | 19:23 |
| smoser | roaksoax, no | 19:24 |
| smoser | the error is because its a confffile | 19:24 |
| smoser | and you (postinst) edited it | 19:24 |
| smoser | and then upstream changed it. | 19:24 |
| roaksoax | smoser: yep | 19:24 |
| roaksoax | smoser: i'm awayre | 19:24 |
| smoser | and dpkg is saying "this is changed from what it was before" | 19:24 |
| smoser | so you need to handel that. | 19:24 |
| roaksoax | I have not yet thought on a fix for it | 19:24 |
| roaksoax | smoser: yeah I'm aware of that | 19:24 |
| roaksoax | smoser: i have been giving priority to other stuff | 19:24 |
| smoser | and on the other quantal instance that i installed stright to the ppa | 19:25 |
| roaksoax | smoser: but basically i will just replace the file and not prompt that, and simply send a message saying that if custom settings have been made, they will have to bemerged | 19:25 |
| smoser | i'm getting a stack trace | 19:25 |
| smoser | on during install | 19:25 |
| roaksoax | smoser: that's probably an older package of quantal | 19:25 |
| roaksoax | smoser: as the newer ones are precise | 19:25 |
| roaksoax | since sabdfl wanted to test precise | 19:25 |
| roaksoax | so dind't upload quantal | 19:25 |
| roaksoax | smoser: again, I will test quantal again tonight to see if the issues i found were fixed upstream, if so I will release to archive | 19:26 |
| roaksoax | smoser: brb, need to change locations | 19:26 |
| smoser | roaksoax, the stack trace i'm seeing is on the daily ppa | 19:26 |
| roaksoax | smoser i think i know why that is | 19:48 |
| smoser | roaksoax, hm.. i dont know what i did to cause the stack trace. but i didn't reproduce it with this | 19:56 |
| smoser | sudo sh -c ' | 19:56 |
| smoser | apt-add-repository ppa:maas-maintainers/dailybuilds -y && | 19:56 |
| smoser | apt-get update && | 19:56 |
| smoser | DEBIAN_FRONTEND=noninteractive apt-get --assume-yes install maas' </dev/null | 19:56 |
| smoser | roaksoax, what is the dhcp server? | 19:57 |
| roaksoax | smoser isc-dhcp | 19:57 |
| roaksoax | smoser its an issue when regenerating passwords it is not doing it right because a configfile was changed without updating packagaing | 19:59 |
| smoser | roaksoax, so after the above... | 20:00 |
| smoser | i should have maas-dhcp running | 20:00 |
| smoser | right? | 20:00 |
| smoser | roaksoax, ping when you get a chance. | 20:11 |
| roaksoax | smoser: sorry about that, internet sucks at the moment | 20:28 |
| smoser | ok. | 20:29 |
| smoser | you ahve a minute now? | 20:29 |
| roaksoax | smoser: yes | 20:29 |
| smoser | k. | 20:30 |
| smoser | so. after i installed maas from the ppa | 20:30 |
| smoser | i dont have any isc-dhcp running | 20:30 |
| smoser | should I ? | 20:30 |
| roaksoax | smoser: not really unless you have it enabled on MAAS webiui | 20:31 |
| roaksoax | as it is the one that controls the start/stop of the daemon | 20:31 |
| smoser | how can i enable it? | 20:31 |
| roaksoax | smoser: Settings on the WebUI | 20:31 |
| roaksoax | smoser: note that you will find yourself with the bug that it is unablke to write /etc/dhcp/dhcpd.conf | 20:31 |
| smoser | no other way to enable? | 20:32 |
| roaksoax | smoser: nope | 20:32 |
| smoser | so it asks me about what settings i want for the dhcp server | 20:33 |
| smoser | but not whether or not to run it | 20:33 |
| smoser | nice. | 20:33 |
| roaksoax | smoser: that's upstream issue | 20:34 |
| roaksoax | smoser: the package simply sets up the master dhcp pool | 20:34 |
| roaksoax | smoser: the only way to enable the dhcp server is by doing it from the webui | 20:34 |
| roaksoax | smoser: i thnk that they were gonna change the default sto have the dhcp server enabled by default | 20:36 |
| roaksoax | smoser: brb | 20:40 |
| roaksoax | smoser: did you get it working? | 21:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!