[00:17] Can I config sshd to listen on multiple ports? [00:17] yes [00:17] Like, in /etc/ssh/sshd_config, put in more than one "Port" listing? [00:17] have multiple Port lines [00:17] k [00:18] Because not all programs that remote in take a custom port switch, but when I'm off my dorm LAN I can't get on port 22 [00:19] i suspect yourdoingitallwrong (tm) [00:20] ;_; [00:22] Kamping_Kaiser: how then, do I get virt-manager to tunnel ssh on a custom port? [00:22] lukehasnoname, no idea what that is (and i cant stay around to help, because i'm off to work [00:22] gl with it [00:23] later. [02:04] packages.ubuntu.org says that hardy has postgresql 8.3.1 and really has 8.3.3 same for gutsy says postgresql 8.2.6 and really has 8.2.9 [02:34] mathiaz: it looks like lucas is mad with you [02:34] :S [02:48] nxvl: lucas isn't the only one. [02:52] mathiaz: That gems change got no support when it was discussed. Why in the world did you upload it? [02:53] ScottK: being mad doesn't help to fix things is better to discuss it calm'd down [02:54] nxvl: I'm not upset now. I think it showed very poor judgement and distrespect for the community. [02:54] ScottK: I reread the thread and I didn't find there was strong disagrement about not doing it. [02:54] mathiaz: Nobody was in favor. [02:55] mathiaz: It is wrong all the way around. [02:57] OK. I take that back. Darren Hinderer liked it. [02:57] But given that he's a RoR developer he would. [02:58] nxvl: Propose a fix then. [02:58] hat do i broke now? [02:58] ScottK: IIUC, your main concern is that binaries installed by the gem commands are located in /usr/local/bin and that would take precedence over binaries in /usr/bin ? [02:58] The RoR thing. [02:59] From a packaging/technical perspective yes. [02:59] Not having reviewed the code, I didn't understand the degree to which you were forking the package. [02:59] That's a serious concern too. [02:59] ScottK: so you have to serious concerns ? [03:00] Yes. [03:00] ScottK: or only the fact that there is a serious fork ? [03:00] The fork and random versions taking precdence over system installed packages. [03:00] Two. [03:01] ScottK: on the packaging bits, we're using hooks that are in upstream code repository - so when 1.3.0 is out, the debian maintainer will be able to use it. [03:01] ScottK: I agree that changing the patch system is the best move. [03:01] I think that was VERY bad. [03:01] ScottK: OTOH all patches in 1.2.0 are included in upstream code. [03:01] That's not relevant. [03:02] ScottK: so once 1.3.0 is package there isn't patch system needed anymore [03:02] Say lucas thought your change was wonderful and wanted to incorporated it? [03:02] You've built your change set in a way that's incompatible with his package and made it much harder than it needs to be. [03:02] ScottK: incorporate it in the current version of debian (lenny) ? [03:02] It shows you've no intent of working with Debian. [03:03] Possibly. The point is you did your change in a way that makes it hard to feed back to Debian. [03:03] Whether he tries to get a freeze exception or not is up to him. [03:03] We shouldn't presume. [03:04] Ubuntu tries to show it works hard to push things back to Debian and then incidents like this put us in a very bad light. [03:04] I think as far as that goes lucas reaction to the change speaks for itself. [03:04] ScottK: if Lucas wants to incorporate our work, he can just grab the debian/operating_system.rb [03:05] Keep in mind that as Debian developers go, he's very pro-Ubuntu. [03:05] What possible benifit was there to change the patch system? [03:05] ScottK: that's where all the update-alternatives plumbery is done. [03:05] ScottK: none - it was not a move as I stated before. [03:05] OK, but he still has to redo the patches or redo his package. [03:06] ?? [22:01] ScottK: I agree that changing the patch system is the best move. [03:06] ScottK: there isn't any patches to do to implement the update-alternatives system. [03:06] But there are patches and you did change the patch system. [03:06] ScottK: debian/operating_system.rb relies on hooks that are already in upstream. [03:07] ScottK: correct - there is 1 patch. [03:07] Right. so lucas could, if he wanted either wait and get the new upstream or he could redo all the patches, what he cannot do is take advantage the Ubuntu patch without rework. [03:08] ScottK: the current 1 patch in Ubuntu relies on upstream hooks IIRC - so lucas would have to update to the new upstream version first. [03:08] OK. [03:08] He still can't use the patch without rework. [03:08] What's the name of the offensive package again? [03:09] ScottK: correct - as I said, changing the patch system wasn't a good idea [03:09] soren: libgem-ruby [03:09] soren: libgems-ruby [03:10] mathiaz: I think you may have had a typo earlier [03:10] mathiaz: about the patch system [03:10] ScottK: sommer correct [03:11] ScottK: I made a typo before - unfortunately it was a typo at a bad moment [03:11] OK. [03:12] ScottK: so what was your other concern ? [03:12] files installed by gems taking precedence over ones installed through the packaging system. [03:13] This isn't the usual /usr/local situation where we can assume that if the admin installs something in there he want's it to take predence. [03:13] ScottK: so binaries installed by gems are available in /usr/local/bin/ which takes precedence over package system. [03:13] Yes. [03:14] ScottK: why - he is using the gem command to install something that is not in the archive ? [03:14] How are these different scenarios? I know nothing about gems or the issue at hand. I'm just curious. [03:14] mathiaz: Gems embed the entire application stack that they need. [03:14] soren: ubuntu-motu ML Lucas mail [03:14] They have no idea what's already installed. [03:15] soren: imagine that you use easy_install and get a script in /usr/local/bin automatically. [03:15] Except more crackish, less integrated, and more opaque. [03:15] So a Gem always brings everything IT needs. Regardless of the installed state of the system. [03:16] ScottK: right - and ? [03:16] The Gem installing stuff in a location where it can find it, but is not in the system path is a reasonable compromise and about the best one could do today. [03:16] mathiaz: So it's the RoR equivalent of DLL hell. [03:17] ScottK: Ok. Even stuff that's already installed? It only assumes the presence of a ruby interpreter? [03:17] soren: As I understand it, yes. [03:17] soren: yes - the gem command doesn't know about the ruby libraries installed by dpkg/apt. [03:17] ez_install has at least been patched into submission to know about stuff that's already installed through that package management system. [03:17] This is much worse. [03:18] soren: it still knows which one it has installed though. [03:18] mathiaz: Well, it wouldn't have to know about packaging systems. It could just do an "import foo" (or whatever it's called in ruby) and see if it works. If not, go fetch the missing crack. [03:18] The problem is that other packages will use the selected alternative in /usr/local/bin. [03:20] ScottK: ok - so if a package relies on a binary from a specific gem, and there is another version of the gem installed with the gem command, the deb package would use the version in /usr/local/bin instead of the one provided by the corresponding package. === anonimous is now known as YoMero [03:21] Right. Or if there happened to be the same file installed via the packaging system (recall \sh's imagemagic example). [03:22] ScottK: don't remember - could you give me example ? [03:24] The example he gave was, "I had this at one ocasion, there was this imagemagick gem and this module was only working with a special imagemagick version, so it shipped it together with the other cruft, but instead of installing it somewhere where this imagemagick lib didn't hurt, it was just a smartass and installed it in /usr/lib, overwriting the distro imagemagick." [03:26] ScottK: right - that's was a problem with the upstream gem, which was bad. I don't see how the version I've uploaded would have made thins worse in that case ? [03:27] Right, but if it'd let it be installed in a 'normal' place instead of forcing things, then with your change, it's in /usr/local and even though it doesn't overwrite the distro version, the effect is the same. [03:27] ScottK: I take this as an example that there exists upstream gems that are wrong. [03:28] ScottK: I don't understand what you meant. what would be in /usr/local ? [03:28] ScottK: only the binaries declared by the gems would have a symlink in /usr/local/bin [03:29] ScottK: all the rest would end up in the usual place (/var/lib/ruby1.X/gems/imagemagick) if the gem was using the gem calls [03:29] ScottK: or in /usr/lib if the gem was bypassing everything [03:29] nothing should be added to /usr/local by any package [03:29] THe right fix isn't fixing gems, its packaging ruby gems into APT, just like python and python debian groups do [03:29] NCommander: the libruby-gem package doesn't add anything to /usr/local/. The gem command does everything. [03:30] mathiaz, it symlinks things into /usr/local [03:30] Thats enough to be a policy violate [03:30] or should I say [03:30] It configures gems to do that [03:30] NCommander: *it* = the gem command, not while installing the libruby-gem package. [03:30] A bad policy at best since then apt can't remove everything correctly [03:31] If you want to wreck the consistancy of users systems, then having gems's package manager exist at all is a miserably idea [03:31] Neither perls' CPAN or php's PEAR are supported [03:31] We repackage all those modules [03:33] NCommander: slangasek responded on bug https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/262063 [03:33] Launchpad bug 262063 in libgems-ruby "rubygems bin in PATH potentially breaks other applications and violates all sense of decency in packaging." [High,Confirmed] [03:34] I think slangasek is right about that. [03:35] We aren't actually installing stuff in /usr/local. We're just a faciliator. [03:35] Ok [03:35] I conceed the point [03:35] But I still think its bad practice to allow gems to install packages outside of APT's control [03:36] Doesn't make it a good idea however. [03:36] Having multiple package managers is kludgy at best [03:36] Just because you are dealing the crack instead of injecting it doesn't make you innocent. [03:36] Can you install CPAN module directly from perl ? [03:36] yes, you can, but its depericated [03:37] Its only recommended if your running unstable, and the module you need is not available via any other means, and even then its still discouraged [03:37] (it ends up in /usr/local I believe, so it will still override any package installed by APT later on) [03:37] Just as you can install Python modules through distutils or ez_setup. One fo the big differences though is that even ez_setup knows what modules are already installed. [03:37] right - but it's still possible. What is the difference between doing a gem install something and download a tarball and ./configure; make; make install ? [03:37] Because that should be a method of last restort [03:37] If a package is not available via APT [03:37] Fine, install it via gems [03:38] But thats the only case [03:38] The correct and proper solution is to package the gems individually [03:38] But don't have the gems functionally replace stuff that's installed through the package system. [03:38] NCommander: I don't deny that. but what if they're not available ? [03:38] mathiaz: Then don't put it in the path where it can mess other stuff up. [03:38] mathiaz, the user should be able to use gems, I agree, but it should not go into the PATH, and not affect the general usage [03:39] Make sure gems prints a giant warning label [03:39] ScottK: well - as stated by NCommander, if you install CPAN module, it will override the system modules. [03:39] I consider that a bug in CPAN [03:39] Its because Perl offers no alternative [03:39] mathiaz: That doesn't make it a good idea. [03:39] so what's the point of having /usr/local/bin on the path then ? [03:39] mathiaz, thats for things users install themselves. Its didicated by FHS [03:40] that may have actually changed in recent years, I haven't needed a perl module that wasn't packaged in APT in a very long time [03:40] NCommander: exactly - and how does a end user install ruby library ? [03:40] sudo apt-get install libruby-gems-*name* [03:40] NCommander: via the gem command, instead of ./configure; make; make install [03:40] I'm telling you [03:40] NCommander: and if it's not available ? [03:41] * NCommander feels like a broken record [03:41] Right, but it doens't just bring itself, it brings an entire applicaition stack. [03:41] And that's the difference. [03:41] Then its the users responsibility to install it and possibly shoot themselves in the foot [03:41] ScottK: it brings the dependencies needed to make the gem running. [03:41] Which can include binary modules [03:41] Yes, whether they are alerady installed or not. [03:41] Which may have bugs or break the ABI with things already installed [03:41] Assume it installs an expat update that breaks the ABI [03:41] NCommander: correct - via the gem command - we're not trying to support ruby libraries installed via gem. [03:42] SUddenly GNOME doesn't wor on the next restart [03:42] mathiaz: If I install a perl module or make install something I see what I get. [03:42] ScottK: you can also do that with the gem command [03:42] If I install a gem, there's a whole train behind it that I don't necessarily get to see until it's to late. [03:42] mathiaz: But that's not the typical RoR usage. [03:43] mathiaz: I don't understand why each Gem can't just live in it's own private namespace and not disturb anything. [03:43] It's going to bring the whole stack anyway, so it's not like it causes more code duplication. [03:44] ScottK: what's the typical RoR usage ? [03:45] Developer bangs out cool looking application, stuffs it into a gem module and delivers it and moves onto the next project. [03:45] you install a gem [03:45] gem installs libraries [03:45] ScottK: I agree that being able to teach the gem command to check if there is already a ruby library installed by dpkg/apt is another step in the right direction. [03:46] YOu install another gem which installs another version of the same library [03:46] mathiaz: I just don't understand why being in the path is of any benifit. [03:46] All I see is downside risk. [03:46] Having gems as a package manager exist separately is insane if the distribution provides a package manager [03:47] ScottK: I would argue for user friendlyness [03:47] ScottK: if you install the rails gem, you'll get a rails binary [03:47] ScottK: the rails binary relies on the rake binary to be called. [03:48] ScottK: so the rails command doesn't work by default if you haven't modified your path [03:48] mathiaz: So modify the path. [03:48] I'm not at all convince I shouldn't just revert this entire uplaod. [03:48] It doesn't make any sense at all. [03:49] Note: I'm not actually doing that. That's just my perspective. [03:50] ScottK: well - the reason for doing this upload is so that you won't have to modify the path. [03:51] Yes, you can just destroy your system instead and that will be better. [03:51] mathiaz: Doesn't ruby have the equivalent of sys.path.append? [03:52] In Python at least this is the most trivial thing to do in the world. [03:52] ScottK: by destroying the system you mean that the end user could install random binaries in /usr/local/bin ? How is that different from an end user using ./configure; make; make install ? [03:53] If that had the potential to drag in lots of not clearly related files and superced system functions, I'd agree. It generally doesn't. [03:53] The problem is that Gems aren't at all transparent about what they will bring with them. [03:54] So the admins sees X and wants it and doens't now about Y, Z, and AA. [03:54] AA causes problems and he didn't even know it was there. [03:54] now/know [03:54] ScottK: there is the dependency command in gems. [03:55] So you're telling me that any admin who installs a gem has a clear understanding of the dependencies he's bringing and what that might affect? [03:56] mathiaz: What's the problem with an installed gem extending it's path to include what it needs? [03:59] ScottK: hm - it may possible to patch the ruby interpreter to include the /var/lib/ruby1.X/bin/ in it's path if it exists. [03:59] That would resolve most of my technical concern. [04:00] ScottK: however any shell scripts coming the gem would work [04:00] ScottK: *would not* [04:00] Right. [04:01] ScottK: but that would still require the end user to modify its PATH to include /var/lib/ruby1.X/bin/ [04:02] ScottK: so that he can use the gem binaries directly. [04:02] ScottK: that's the issue the upload is trying to solve. [04:02] Surely we can figure a way to add that to the environment for that user/gem. [04:03] ScottK: well - according the lsb you can drop things in /etc/profile.d/ [04:03] Put the main application in /usr/local/bin and then stuff all the dependencies in /var/lib/ruby1.X/bin/ [04:03] ScottK: however, this violates the debian policy. [04:04] Then the gem can be started, we just need a way to have it notice /var/lib/ruby1.X/bin/. [04:04] ScottK: well then all the binaries would end up in /usr/local/bin/ [04:04] ScottK: let's take the example of rails [04:05] ScottK: the rails gem provides the rails binary. [04:05] ScottK: and depends on the rake gem. [04:05] ScottK: but you'd also want to have the rake binary available on the command line. [04:05] ScottK: so while installing the rails gem, it would pull in the rake gem [04:06] ScottK: the rake gem should install the rake command on the PATH since a end user may want to be able to use the rake command. [04:06] Which puts us on the road to perdition. [04:06] I see you want it entirely the way it is then. [04:07] I guess there's no point in further discussion. [04:07] I'll just have to consider if I want to take the heat for reverting it or not. [04:17] (linux newb) I'm trying to install Ubuntu server 8.04.1, but I keep running into this error - "Please insert the disc labeled: 'Ubuntu-Server 8.04.1 _Hardy Heron_ - Release i386 (20080701)' in the drive '/cdrom/' and press enter. Media change [04:18] i md5d the iso, verified the disc integrity, and am pretty sure the cdrom drive is not at fault, as it always fails at the same point (78% into the base system installation) [04:19] I tried the forums, but althought I found others with the error, I could not make out a solution [04:19] anyone know what to do / have any ideas? Thanks === hessml|away is now known as hessml|away|away [04:22] deleter: Did you try more than one CD anyway? [04:23] yeah I'm on my 4th one... [04:23] OK. [04:23] No great ideas on my part then. [04:32] have you attempted to download the iso from a different location and burning it from it? [04:34] yes, I don't think its the iso though because the hash matched the one online === hessml|away|away is now known as hessml|away [04:43] not sure if this is the right place, but can anyone tell me where my inputted ufw rules are stored? [04:43] /etc/ufw/ iirc [04:44] I see before.rules and after.rules, but don't see any of my custom rules in those files. [04:45] you wont see the rules per-se, just the iptables [04:45] deleter, then suggest trying another machine to do download and burn and see if that helps ... if it doesn't .. then could be drive you are using to read disk on ... [04:46] wantok: right. I'd like to manually edit a few of the iptables lines (i have a few in incorrect order) [04:46] problem is I just can't see any of my rules in ufw or iptables syntax [04:48] ahh, its in /var/lib/ufw. [04:59] ScottK, one question I have is what will best serve the average ruby or rails developer. if gems is really popular, along with capistrano, and keeps things in sync itself, and deals with security issues, and works in a nice cross-platform way and allows users to track upstream better than ubuntu is likely to do, then we have to deal with that use case. we could either explain to users how to do it ENTIRELY outside the package [05:00] turns out it was the cddrive, use of a different one led to success, thanks for the ideas [05:00] nealmcb2: None of which is an argument for putting every single gem that gets brought in when you install something in the system path. [05:01] nealmcb2: Not to mention the social aspect of blowing off every developer who gave comment on the ML and gratuitously forking the package from Debian. [05:03] deleter: you are welcome .... [05:03] I certainly hear the frustration, and also agree with steve that it is a tough situation. I haven't looked enough at the issues to say what the best path forward right now is [05:04] but I suspect we do want to figure out how to make it easy for users to use gems and capistrano [05:05] too bad the conversation that was started back a few months ago never really got off the ground [05:08] ScottK: finding ways to leverage the expertise of both ubuntu devs and ruby/gems devs is one challenge, from what I have seen [05:08] (and debian :) [05:09] We have a package management system and in the event of a conflict between that and something else, I have no doubt which we should go with. [05:11] then at this rate from what I'm hearing I'm guessing that we won't be much of a platform for ruby. but that is just a guess, since I haven't looked at it in detail [05:12] The problem is that no attempt was made to try and make it work with the packaging system. [05:12] Every language that has a packaging system has to do this. [05:12] It's painful, but necessary work and they wanted a shortcut. [05:13] that could well be the case. but dealing with conflicts between packaging systems is even harder than dealing with conflicts within a single packaging system [05:14] anyway I'm hardly the packaging expert. I'm mainly trying to hold up a common use case and hoping we can address it [05:15] Right. That's the hard part. [05:15] I thought we were having a good discussion towards compromise and all of a sudden he pulled back. [05:16] nealmcb2, I'm not upset with you over this patch, I'm upset with the people who approved it. [05:16] nealmcb2, and I can see it from your side of things, and at first glance, your solution isn't that bad until you realize what it means for APT :-) [05:16] and I hope this doesnt' discourage you from futher ruby contributions [05:16] nealmcb2: Was this your idea? [05:17] and I'm hoping we can appreciate folks for putting possible solutions forward, and recognize the inherent difficulty of the problems, without too much unhelpful venting. [05:17] * NCommander re-reads the original bug description [05:18] ScottK: nope - not my idea.... [05:18] OK. [05:18] Well, I personally want to see the bad patch get wiped [05:18] I did facilitate the server team meeting where it came up last week, but I was concentrating on the agenda, not the technical decisions === nealmcb2 is now known as nealmcb [05:20] The proper method is we collabrate with Debian on packaging gems individually === hessml|away is now known as hessml|away|away [05:23] NCommander: how much do you know about how the average ruby and/or rails user works? My sense is that gems is very widespread, but I haven't researched it a lot [05:24] Very little [05:24] I've tried Ruby on Rails [05:24] are you still fighting about the gems issue? [05:24] But I felt like I was fighting the tool more than anything else [05:26] yeah - I think that's our problem - lots of ubuntu/debian expertise and not enough ruby user perspective [05:26] I find ruby on rails ATM to be more hype than being super-revolutionary. [05:26] http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html [05:26] nealmcb, the way ruby does things with gems is the same problem we have when a user uses CPAN or PEAR directly [05:27] of course. and it is a hard problem. [05:27] (I'm familiar enough with gems to understand why its a bad thing the current setup, but I can't say I could build a gem now) [05:27] Django is kewl [05:27] nealmcb, the right (not the easy) solution would be to build a framework that can take a gem, and convert it to a debian package [05:28] NCommander: and have folks installing packages from random repos? with no security backing? [05:29] We can generate source packages that are part of the archive [05:29] The Debian perl group have a set of scripts for quickly debianizing cpan modules [05:30] I think one aspect of this is that the ruby world is still moving very fast. perhaps it will mature enough that our packaging will catch up. anyway, I'm just hoping we can come up with a good answer, sooner rather than later [05:31] for non-root users doenst cpan install into ~/.cpan? [05:32] wantok, yeah [05:32] My personal feelings on ruby ATM though are generally its more hype then anything else [05:32] It requires you to fight to a specific methodology [05:32] Reminds me of MFC actually [05:32] s/fight/think [05:33] i dont know how ruby's thing works at all, but if it doesnt do the same thing its not really the same as cpan at all [05:33] wantok, gems doesn't support (to my knowledge) local user installations [05:33] Perl and CPAN have almost 30 years of code behind them [05:34] i dont deny it, i just felt i should note hte difference between the perl 'you can shoot everyone or just yourself' and the (percieved) gems 'shoot everyone, or anyone' [05:37] I think with perl it is [05:37] "You can shoot yourself in the foot, but six months later, you'll have no idea how you did it" [05:38] nm. you have regex to save yourself ;) *mwhwhahahaah* [05:39] well, python working to kill perl as the glue language === wantok is now known as kgoetz === [1]deleter is now known as deleter === hessml|away is now known as hessml|away|away === hessml|away|away is now known as hessml|away [07:15] hi all [07:15] Soft RAID1 problems (invalid raid superblock magic), ubuntu server 8.04.1, anyone? [07:18] Hey guys. I have a rather stupid question. If I have a dir A, with dirs a,b,c, and a dir B, with dirs d,e,f. If I do a mv B/ A/ will it overwrite dirs a,b,c? [07:27] mm_202: No, it will move directory B inside of A, giving you A/a A/b A/c and A/B/d A/B/e A/B/f [07:29] Sorry, I meant mv A/ B [07:29] to just move the contents of A to B. [07:30] mm_202: Well, go into the /tmp directory, then run mkdir -p A/a A/b A/c ... etc and test it for yourself. [07:30] okay, will do. [07:30] thanks, owh. [07:39] toshko: I cannot help you directly, but perhaps if you asked an actual question, someone here might be able to. [08:10] owh: well this is the problem: install, configure raid1 with sda,sdb and the folowing message appears on random basis at the start up screen (this is from the syslog file but the same is shown at the start). [08:10] md: invalid raid superblock magic on sda [08:10] md: sda does not have a valid v0.90 superblock, not importing! [08:12] this is since ubuntu server 7.10 for me on several machines [08:14] toshko: Are the machines running the same hardware? [08:15] no, it is not hardware issue, because the machines are different and i changed the mb and psu on the last one [08:15] tested the hdds - no problem [08:17] Given that you've been having this issue for some time, I'd recommend putting your question with relevant background information, including the things you've tried and the hardware involved into an email and sending it to the ubuntu-server list. [08:18] did it in the forum but will do in the list also [08:18] thanks [08:19] toshko: Also, make sure that you don't get stuck into a single thought pattern, as-in "it's not hardware because...", you may well find the solution in a place where you didn't expect it. [08:49] Elo [08:54] In ubuntu-8.04-server-amd64.iso the pxeboot install installs the server kernel. Any ideas how I can change this? [08:57] CrummyGummy: The last time I looked at this was a little while ago, so what I'm telling you is not going to be accurate, but IIRC, you can configure exactly what happens with the appropriate config file. I recall setting it all up with several boot images and menu options. As I said, this isn't directly going to help. [08:58] CrummyGummy: The pxeboot process from memory works like a TFTP server which you can configure to use different boot images. [08:59] CrummyGummy: It sounds like you're using a ubuntu-server boot image, rather than a workstation. [08:59] Sorry, I'm half a sleep still. [09:00] The problem is that the server iso is installing a generic kernel, not the server kernel as expected. [09:02] CrummyGummy: Uhm, which boot stanza are you using because I think it might be pointing at the wrong thing. [09:03] (Bear in mind that as I said before, I've not done this for some time...) [09:06] This is the current http://pastebin.com/m1c460e6a [09:07] pxelinux.cfg [09:08] CrummyGummy: Well that's using the ubuntu-installer initrd, so I'd not be surprised if it's using the workstation kernel. [09:09] CrummyGummy: Where did the initrd come from? [09:10] That initrd came from the ubuntu-installer directory on the server iso. [09:10] (sorry, was on the phone) [09:10] CrummyGummy: You're sure that's where it came from, as-in, no mistake? [09:11] And while we're at it, there isn't another ubuntu-installer directory lying around anywhere? [09:12] CrummyGummy: The way I implemented this at the time was to loop mount an .iso of the required installer and make sym-links to the right bits, so I could just change the iso mount and make it install something else. [09:13] I'm pretty sure that it came from that iso. Its the only amd64 iso I have on this server. [09:14] as in no workstation ones. I'll try again with the symlinks as suggested. [09:15] CrummyGummy: There are no stray ubuntu-installer directories? [09:15] Runnign find. [09:15] use locate -i [09:17] Hey guys. I tried installing Ubuntu 8.04 Server on an old P3 Box. I put the disc in and booted then it loaded the cd and displayed the menu. When I clicked install not the "try ubuntu livecd" option it still took me to the live cd. [09:17] elnewb: Well, the server CD doesn't have a LiveCD, so you're in the wrong room :) [09:18] Owh: are you sure? it gave me the option? [09:18] it booted into the comand line but it was running off the disc. [09:18] It's possible that I'm getting old and grey and I'm wrong. [09:21] Wait you are right..... just loaded the ubuntu iso in vmware [09:21] Pfew. Thought my brain had finally had it :) [09:22] This was at school today. My teacher must have downloaded the wrong version. [09:32] elnewb: Well before you download another one, check the MD5 [09:34] Nah I don't think thats the problem. I asked my teacher to download the server version for me cause the students access to the internet is filtered so we are limited to direct downloading of documents (.doc .xls and pdf). [09:35] elnewb: No, I mean, check which CD you have. [09:35] elnewb: Not if it's corrupt or not :) [09:35] owh: the iso will still be on the computer that he downloaded it toos desktop [09:35] probably be like 8.04-desktop.iso [10:03] moin [10:05] tag [10:05] Or should that be 'tag ? [10:40] Okay, I've done it with symlinks to pxeboot stuff from the right iso. In the install process I chose Openssh server only. The kernel installed is linux-generic. Is this right? [13:36] good morning [13:46] New bug: #262244 in mysql-dfsg-5.0 (main) "Post-installation script error reinstalling mysql" [Undecided,New] https://launchpad.net/bugs/262244 [14:04] I have setup a mailserver (postfix+maildrop) [14:04] as a mailbox_command I have defined maildrop [14:05] so the user needs a $HOME/.mailfilter to function properly [14:05] since i made it generic, I have copied the .mailfilter to /etc/skel [14:05] when I create a new User, the file gets copied, but the permissions stay on root:root [14:06] any suggestions on where to tell that the permissions need to be updated as well? [14:11] is it possible to only reinstall grub and the mbr with the server cd? [14:11] New bug: #262251 in php5 (main) "phpize: configure:8184: error: possibly undefined macro: _LT_SET_OPTIONS" [Undecided,New] https://launchpad.net/bugs/262251 [14:41] New bug: #262264 in likewise-open (main) "Fails to join a domain: Unknown pam configuration" [High,New] https://launchpad.net/bugs/262264 === hessml|away is now known as hessml|away|away === hessml|away|away is now known as hessml|away [15:11] i have two shadow files: /etc/shadow and /etc/shadow- i need to copy some existing users from another system. which file should i edit to put the password hashes in? [15:46] New bug: #262291 in samba (main) "hardy: update samba to 3.0.32" [Undecided,New] https://launchpad.net/bugs/262291 === inetpro is now known as hibana [16:45] hey does anybody here know anything about raid? [16:46] anyone here? [16:46] had to sound like a retart [16:46] *retard [16:46] but i'm using pidgin for the first time to connect to IRC [16:46] toyotafosgate: well, I know something about raid. [16:46] fair enogh [16:46] but maybe not enough, depends on your real question [16:47] so heres the deal: I have two hard drives mirrored (raid1) [16:47] they are mirroring only one partition [16:47] they are mirroring /home [16:47] i noticed that they were not synced [16:47] so i synced them [16:48] sorry, got to go now -- i'll see your question later if nobody else picks it up before [16:48] this caused the server to go down [16:48] alright [16:48]