00:20 | achandrashekar_ has joined #ltsp | |
00:22 | <achandrashekar_> Hello. I have been researching some solutions for a lab setup. I came across setting up two ltsp servers of which one has ldap server installed. Past that I am confused as to "How" it works. From a client perspective that is. Can some one clarify the architecture?
| |
00:24 | <FuriousGeorge> can anyone recommend a thin client that mounts elegantly onto an LCD?
| |
00:25 | achandrashekar_: im just researching too, but it appears ltsp is a way of managing chroot environments for diskless clients
| |
00:25 | they boot up off the network, and find their /boot and /root there
| |
00:25 | they just run X
| |
00:26 | <johnny> yes
| |
00:26 | ldap would be for the servers to share user accounts off of
| |
00:26 | <achandrashekar_> the out of the box ltsp part is not an issue..considering id use something like edubuntu
| |
00:26 | but the multiserver setup which i have been researching all day points me to ldap
| |
00:26 | instead of nis
| |
00:26 | <johnny> use ldap
| |
00:26 | yeah
| |
00:26 | there are docs
| |
00:27 | you don't need any ltsp specific setup afaik
| |
00:27 | <achandrashekar_> the docs!--are here - ? http://www.ltsp.org/twiki/bin/view/Ltsp/LDAP?
| |
00:28 | i followed as best as I could but Im really confused about the actual setup
| |
00:29 | <johnny> what do you mean?
| |
00:29 | <achandrashekar_> i planned on using one ltsp server with ldap on it. (i suppose ill need a client on the same box to authenticate with) and then the second box with ltsp authenticating to the first?
| |
00:29 | <johnny> yes
| |
00:29 | <achandrashekar_> how does the client know which box to get dhcp info? and tftp boot stuff to boot up?
| |
00:30 | <johnny> it gets it from the box it is connected to
| |
00:30 | or are you not segmenting it?
| |
00:30 | <achandrashekar_> not segmenting
| |
00:30 | ie..i planned to connect to same lan
| |
00:31 | because "i thought" that'd be how it works..but i must be mistaken by the setup
| |
00:31 | is the setup /doc the right one i was looking at or is there a clearer one?
| |
00:31 | <johnny> well that ldap stuff doesnt have much to o with it
| |
00:31 | this is for after
| |
00:31 | <achandrashekar_> i think im just confusing myself.....as usual :)
| |
00:32 | <johnny> that's only for auth i think
| |
00:32 | after everything is already working
| |
00:32 | <achandrashekar_> johnny would you mind a walk through or point me in the right direction for the setup...somewhere i am messing up my own perceived logic of how things should be hooked up.
| |
00:32 | <johnny> i've never done anything so intensive
| |
00:32 | my setup is only 4 pcs
| |
00:33 | and even at the 2nd location, i'm maxing out at 20
| |
00:33 | <achandrashekar_> i see.
| |
00:33 | <johnny> i'm just going by what i've read
| |
00:33 | <FuriousGeorge> johnny: must it be dhcp / ldap? if you always wanted the same clients to boot off the same server couldnt you do a static netboot
| |
00:33 | <johnny> you could do static
| |
00:33 | but at the very least it seems like you could do the assigning in the dhcp server
| |
00:34 | <FuriousGeorge> johnny: assigning the boot by mac address to correct pxe server?
| |
00:34 | <achandrashekar_> ive read across to distinct websites where they have these large environments with ltsp with 4 servers.
| |
00:34 | <johnny> ie: give all in range of 1-20 one tftp file
| |
00:34 | err one nbi.image
| |
00:34 | <FuriousGeorge> gotcha
| |
00:34 | <johnny> that's one way
| |
00:34 | <achandrashekar_> i see.
| |
00:34 | <johnny> that way you still take advantage of dhcp
| |
00:35 | <achandrashekar_> okay.
| |
00:35 | <johnny> i'm not sure if that is the recommended way
| |
00:35 | <achandrashekar_> i was really confused as to how.
| |
00:35 | <johnny> you can prolly minimize it to only serve one instance of the chroot across
| |
00:35 | <achandrashekar_> on the dhcp server...i am aware of "next server" parameter...so i thought that is what is necessary
| |
00:36 | <FuriousGeorge> achandrashekar_: what is it you arent understanding? the client pc doesnt have a disk, so it needs to find its data on the network. its a diskless x terminal with a nice administrative system by ltsp (at least thats how i think of it, i could be wrong)
| |
00:36 | <achandrashekar_> i get that...
| |
00:36 | <johnny> FuriousGeorge, i think he's wondering how they know to talk to one server vs another
| |
00:36 | <FuriousGeorge> ahh
| |
00:36 | <achandrashekar_> yes
| |
00:36 | that is it
| |
00:36 | <johnny> there is no one way
| |
00:37 | the way i suggested is possible
| |
00:37 | and then nfs mounting homes
| |
00:37 | or you could setup one of those clustering file systems :)
| |
00:38 | <achandrashekar_> for example if you have 4 boxes with ltsp, where one is an LDAP master, the others are clients and all authenticate with the LDAP master, then in theory or at least what i have read, the client box can boot of any of the 4 boxes. But yes..johnny's last post is the clue to all of this.
| |
00:38 | <johnny> there is the LTS_SERVER parameter in lts.conf
| |
00:38 | <achandrashekar_> because i get that using nfs as well, indicates mounting of the home drives
| |
00:38 | so in essence a combo of ltsp,nfs, and ldap
| |
00:38 | <johnny> they will have to mount it in the computer they are on
| |
00:39 | dhcp really plays a major part in this..
| |
00:39 | dont forget it :)
| |
00:40 | <achandrashekar_> yeah..
| |
00:40 | so ltsp setup on all of the servers requires dhcp...and hence that is the perplexing part. and all that i can figure out is that it uses some sort of "next server" parameter.
| |
00:40 | <johnny> oh wait.. i wanted to clarify what you said before
| |
00:40 | <achandrashekar_> or something.
| |
00:40 | <johnny> to make sure we are square
| |
00:41 | you said "...then in theory or at least what i have read, the client box can boot of any of the 4 boxes..."
| |
00:41 | <achandrashekar_> yes...is that not correct?
| |
00:41 | <johnny> the user can login to any of those boxes
| |
00:41 | <FuriousGeorge> since we are on the subject, i tend to install ipcop for my clients, which allows you to pass custom parameters to the dhcp server when you set up a fixed lease.... that would probably come in handy for ltsp, no?
| |
00:42 | <johnny> the boxes will prolly always use the same serve
| |
00:42 | server*
| |
00:42 | ie: it won't use one of the 4
| |
00:42 | err
| |
00:42 | it will use a specific one of the 4
| |
00:43 | <achandrashekar_> johnny: interesting..so one box actually produces the "boot" sequence and produces a login screen on the client. However, when actually logging in it logs into one of the 4?
| |
00:43 | and then authenticates to master?
| |
00:44 | <johnny> and then prolly mounts the /home
| |
00:44 | from one of the others
| |
00:45 | how are you going to distribute home directories/
| |
00:45 | if you had a clustering fs , it wouldn't really matter i suppose
| |
00:46 | i don't know what's working well yet on that front tho
| |
00:46 | <achandrashekar_> I see.
| |
00:47 | <johnny> i'd love to do a job that involved deploying ltsp
| |
00:48 | the one deployment i have, is at our coffeeshop
| |
00:48 | <achandrashekar_> cool! - i did a search against what you described and I found this! - http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/multiple-server-setup.html
| |
00:48 | <johnny> i plan on doing a mobile classroom
| |
00:48 | <achandrashekar_> the post above says exactly what you stated.
| |
00:48 | You will need to select one server to behave as the primary server. This server will be used to run additional services, hold users files, and network boot thin clients.
| |
00:48 | Secondary servers will be used only to run desktop sessions. They are simpler, and will be configured to use the central services from the primary server. Installing the package ltsp-server will install required software.
| |
00:48 | sorry for flood
| |
00:50 | <johnny> hmm.. i didnt know it was that detailed :)
| |
00:50 | there's gotta be a nicer way to deploy packages
| |
00:50 | i bet the syncronization could be more automated
| |
00:50 | i also notice a small issue in there
| |
00:51 | <achandrashekar_> yeah...know you see my "slight" confusion..lol
| |
00:51 | but it certainly makes more sense talking it out with you.
| |
00:51 | i will just have to give it a whirl.
| |
00:52 | <johnny> i've learned alot from the one deployment i setup
| |
00:52 | even with just 4 plcs
| |
00:52 | pcs*
| |
00:53 | <achandrashekar_> yeah..this stuff rocks.
| |
00:53 | :)
| |
00:54 | <johnny> if you notice the replication of desktop profiles section
| |
00:54 | it doesn't mention that they can be deployed via http
| |
00:55 | so you can set that to your main server, just like the other stuff
| |
00:56 | <achandrashekar_> yeah..ill have to simply work through a complete install of this and see how it falls into place.
| |
00:56 | the part i am interested in is the ldap authentication of one server against the other, and then having it "actually" work.
| |
00:56 | i think ill learn a bit about ldap in this process.
| |
00:57 | im kind of of "hung up" over it.
| |
00:57 | ;)
| |
00:58 | johnny: thanks for the conversation.
| |
00:58 | will be back tomorrow to report progress.
| |
00:59 | and give it a whirl.
| |
01:00 | achandrashekar_ has left #ltsp | |
01:13 | misui has joined #ltsp | |
01:20 | brillantejcoh has quit IRC | |
01:37 | subir has quit IRC | |
01:51 | emilk has joined #ltsp | |
01:55 | rcy is now known as noneck | |
01:56 | noneck is now known as rcy | |
02:49 | misui has quit IRC | |
03:01 | Q-FUNK has joined #ltsp | |
03:06 | Pascal_1 has joined #ltsp | |
03:13 | muep_ has quit IRC | |
04:42 | <Pascal_1> Bonjour !
| |
05:25 | Egyptian[Home1 has joined #ltsp | |
05:26 | Egyptian[Home] has quit IRC | |
05:35 | mhterres has joined #ltsp | |
05:38 | otavio has joined #ltsp | |
06:05 | F-GT has quit IRC | |
06:06 | F-GT has joined #ltsp | |
06:13 | mhterres has quit IRC | |
06:13 | mhterres has joined #ltsp | |
06:18 | emilk_ has joined #ltsp | |
06:24 | cliebow has quit IRC | |
06:35 | emilk has quit IRC | |
06:38 | moldy_ has joined #ltsp | |
06:38 | moldy_ is now known as moldy | |
06:38 | <moldy> hi
| |
06:38 | i am looking for a good ltsp-compatible thin client to buy in europe
| |
06:39 | can anyone recommend anything? i am having trouble digging out useful information from google
| |
06:40 | <Q-FUNK> moldy: yes, the thincan
| |
06:41 | <moldy> Q-FUNK: looking at their website. is there any info on prices available?
| |
06:41 | Q-FUNK: ahh never mind :)
| |
06:41 | <Q-FUNK> moldy: at the bottom of the page
| |
06:41 | <moldy> found it
| |
06:42 | DBE61 looks interesting
| |
06:42 | jammcq has quit IRC | |
06:43 | <moldy> Q-FUNK: do sound and access to local usb sticks work with the DBE61 and ltsp?
| |
06:44 | <Q-FUNK> yes
| |
06:44 | <moldy> Q-FUNK: nice
| |
06:44 | <Q-FUNK> same as with all other hardware
| |
06:44 | actually, the Geode is pretty much the best supported chipset in Linux
| |
06:45 | <moldy> Q-FUNK: where can i order a device?
| |
06:46 | <Q-FUNK> use the response form
| |
06:46 | <moldy> hm ok
| |
06:53 | i have an ubuntu server around here, is it recommendable to install the ltsp packages from ubuntu (for testing)?
| |
06:53 | <Q-FUNK> yes
| |
06:53 | <moldy> ok, thanks
| |
06:54 | <Q-FUNK> moldy: if you use a thin can, you'll need updated packages for the graphic driver and for X, though.
| |
06:56 | <moldy> for production, i have no problem installing other packages or compiling ltsp myself
| |
06:56 | for testing i will first just use a usual machine i think
| |
06:58 | <Q-FUNK> starting with Hardy, you will not need to compile anything. all the patches have been merged.
| |
06:58 | it's only with Gutsy that you need to update some packages and rebuild the boot image.
| |
06:59 | <moldy> i am running dapper here
| |
07:00 | is that still ltsp4?
| |
07:01 | the ubuntu package is version 0-something :)
| |
07:08 | Pascal_1 has left #ltsp | |
07:10 | <Q-FUNK> dapper won't work
| |
07:10 | too old
| |
07:11 | most of the developments for LTSP happened during Gutsy and Hardy cycles.
| |
07:13 | <moldy> i see
| |
07:13 | "won't work" means what it won't work at all?
| |
07:14 | jammcq has joined #ltsp | |
07:14 | <moldy> (so i shoud install from an upstream package?)
| |
07:15 | mikkel has joined #ltsp | |
07:16 | <Q-FUNK> many graphic drivers were not even in ubuntu back then.
| |
07:16 | also the whole build system was rather archaic.
| |
07:17 | you might wanna consider upgrading to at least Gutsy or even Hardy.
| |
07:17 | <moldy> hm, i will consider it
| |
07:17 | <Q-FUNK> the other thing is that many USB devices were not supported until recent kernels.
| |
07:18 | <moldy> i would prefer not updating for just the first simple test though
| |
07:18 | <Q-FUNK> then you would need to backport a few packages
| |
07:18 | Blinny has joined #ltsp | |
07:19 | elisboa has joined #ltsp | |
07:19 | <moldy> 7.10 is what? gutsy?
| |
07:19 | <Q-FUNK> yes
| |
07:20 | <moldy> hm, wondering how painful an update from dapper to gutsy will be :)
| |
07:21 | <Q-FUNK> good question
| |
07:21 | here, using "aptitude" with the safe-upgrade mode, I generally get smooth upgrades.
| |
07:21 | <moldy> it seems that a directupdate is not supported
| |
07:22 | <Q-FUNK> that's possible
| |
07:22 | ubuntu tends to support only updating from one LTS release to another (in this case 6.06 to 8.04) or from immediately subsequent releases.
| |
07:23 | updating to other releases is also possible, but not supported.
| |
07:24 | <moldy> hmm :-/
| |
07:24 | https://help.ubuntu.com/community/EdgyUpgrades reading that right now
| |
07:24 | what is gksu? i don't have it
| |
07:25 | please don't tell me that update-manager requires a gui...
| |
07:25 | <Q-FUNK> I'm trying to remember which release was dapper?
| |
07:25 | <moldy> 6.06
| |
07:25 | <Q-FUNK> right, the last LTS
| |
07:25 | <moldy> according to tha paage an update to feisty is supported and from there to the next version and so on
| |
07:26 | but it seems they forgot about the server edition...
| |
07:26 | <Q-FUNK> although we're still2 months form the release, it would porbably safer to update to 8.04
| |
07:26 | 6.06 to 8.04
| |
07:26 | <moldy> is there any documentation on how to do that?
| |
07:26 | <Q-FUNK> there's probably instructions about that, since it was the last long-term release.
| |
07:26 | <moldy> what's the codename for 8.04?
| |
07:27 | <Q-FUNK> Hardy
| |
07:27 | <Blinny> Last I read, LTS->LTS was planned for Hardy.
| |
07:27 | <moldy> i assume just changing sources.list to hardy and running aptitude will break all sorts of stuff...
| |
07:28 | Q-FUNK: and the dapper ltsp packages don't work *at all*?
| |
07:28 | for now, i just want to see it "in action" basically
| |
07:28 | <Q-FUNK> moldy: changing sources, only leaving the regular and security lines, then "aptitude update && aptitude safe-upgrade && aptitude safe-upgrade"
| |
07:29 | moldy: dapper packages work but, IIRC they are LTSP 4
| |
07:29 | <moldy> Q-FUNK: that would be ok for now
| |
07:29 | <Q-FUNK> and they only work with old hardware
| |
07:29 | <moldy> for now i just want to do very basic testing, since i have never worked with ltsp before
| |
07:29 | <Q-FUNK> the DBE61 drivers only appeared in Gutsy.
| |
07:30 | <moldy> i am going to test on 8 year old thick client hardware anyway, for now
| |
07:30 | <Q-FUNK> but for basic testing with a diskless computer and a network bootable card, it would work just fine
| |
07:30 | just that IIRC there was no auto-mounting of USB stick and other nic ehtings like that
| |
07:30 | <moldy> basicaly i just want to see that i get the configuration process right, to spot possible difficulties for later :)
| |
07:31 | <Q-FUNK> well, the configuration process also changed between 4 and 5
| |
07:31 | <moldy> but btw, it's really stupid that the only supported application for performing a safe upgrade needs a fscking GUI!
| |
07:31 | <Q-FUNK> a lot of things are much simpler on 5.0
| |
07:31 | mhterres has left #ltsp | |
07:32 | <Q-FUNK> aptitude also works well for performing safe upgrades. it's just that ubuntu is primarily a desktop distro, so they recommend GUI tools for everything
| |
07:32 | what I usually do when I upgrade really old machines is:
| |
07:33 | <moldy> Q-FUNK: hm. their documentation explicitly says not to use apt-get, and says nothing about aptitude
| |
07:33 | <Q-FUNK> aptitude update && aptitude install dpkg aptitude && aptitude safe-upgrade
| |
07:33 | apt-get is deprecated.
| |
07:33 | I agree with not using APT.
| |
07:33 | aptitude is much better.
| |
07:33 | <moldy> anyway, it seems i need to wait for the weekend before i can pursue ltsp any further
| |
07:33 | <Q-FUNK> or actually, make that:
| |
07:34 | <moldy> i cannot risk performing an update on that server during the week it seems :-/
| |
07:34 | <Q-FUNK> aptitude update && aptitude install dpkg && aptitude install aptitude
| |
07:34 | <moldy> Q-FUNK: what exactly do i modify in sources.list and what not?
| |
07:34 | <Q-FUNK> followed by many instances of "aptitude safe-upgrade"
| |
07:39 | slidesinger has joined #ltsp | |
07:56 | moldy has quit IRC | |
08:03 | cliebow_ has joined #ltsp | |
08:18 | Blinny has quit IRC | |
08:28 | Gadi has joined #ltsp | |
08:31 | Q-FUNK has quit IRC | |
08:43 | Q-FUNK has joined #ltsp | |
08:44 | <Gadi> sutula: ping
| |
08:45 | <cliebow_> Gadi:rockS
| |
08:45 | <Gadi> morning, cliebow_
| |
08:45 | :)
| |
08:45 | <Q-FUNK> !g
| |
08:45 | <ltspbot> Q-FUNK: "g" is Gadi!!!!!!!!!!!!!!!!!!!!!!!!
| |
08:45 | <cliebow_> good morning!
| |
08:45 | <Gadi> you're almost better than my morning cup of Joe
| |
08:45 | !Q
| |
08:45 | <ltspbot> Gadi: Error: "Q" is not a valid command.
| |
08:45 | * Gadi shakes his head | |
08:46 | <Gadi> silly ltspbot - doesnt know nothin
| |
08:46 | <Q-FUNK> ah, mon capitaine. the Q continuum is shocked.
| |
08:46 | <Gadi> who knew? Q-FUNK's a trekky
| |
08:47 | <cliebow_> ltspbot factoids search --values
| |
08:47 | <ltspbot> cliebow_: 'ltsp', 'sbalneav', 'icewm', 'frappr', 'wiki', 'debian', 'edubuntu', 'dhcpd', 'greyscreen', 'ltsp42', 'localdev', 'localdev', 'localdev', 'localdev', 'checklist', 'muekow', 'bestltspdistro', 'serversize', 'wireless', 'sound', 'topics', 'integration', 'lts.conf', 'pastebot', 'bootfloppy', 'ltsp5', 'tarball', 'download', 'monkeys', 'ogra', 'nfs', 'nfsnotresp', 'js', 's', 'troubleshooting', (1 more message)
| |
08:47 | <cliebow_> ltspbot:set Q as Q-FUNK!
| |
08:47 | !Q
| |
08:47 | <ltspbot> cliebow_: Error: "Q" is not a valid command.
| |
08:48 | r3zon8 has joined #ltsp | |
08:49 | <cliebow_> ltspbot:set !Q as Q-FUNK!
| |
08:49 | !Q
| |
08:49 | <ltspbot> cliebow_: Error: "Q" is not a valid command.
| |
08:56 | nicoAMG has joined #ltsp | |
09:08 | mccann has joined #ltsp | |
09:11 | Guaraldo has joined #ltsp | |
09:15 | K_O-Gnom has joined #ltsp | |
09:23 | spectra has joined #ltsp | |
09:29 | <Gadi> ogra: u around?
| |
09:35 | emilk_ has quit IRC | |
09:39 | <Q-FUNK> !q
| |
09:39 | <ltspbot> Q-FUNK: Error: "q" is not a valid command.
| |
09:39 | <Q-FUNK> meh
| |
09:43 | <ogra> Gadi, here
| |
09:43 | Gadi, "1. Fix to not add "-X" to ssh cmd when in directx mode" not sure that will work, we might need the -X for the consolekit tunnel
| |
09:47 | <Gadi> ah, good - got my email
| |
09:47 | :)
| |
09:47 | did a lot of ldm-hacking last night
| |
09:47 | starting to look more like a display manager :)
| |
09:49 | <ogra> heh
| |
09:49 | yeah, i'm trying to get my pieces together for the last upstream checout before feature freeze
| |
09:50 | <Gadi> ooh - Id love to get some of these fixes into hardy
| |
09:50 | not restarting X makes a HUGE difference for low-powered clients
| |
09:51 | or funky vid chips
| |
09:51 | <ogra> well, feature freeze means no new upstream version, it doesnt mean i cant add patches to fix bugs ;)
| |
09:52 | <Gadi> ah, the line is so fine you can hardly see it :)
| |
09:56 | makghosh has joined #ltsp | |
10:03 | writeout has joined #ltsp | |
10:06 | <writeout> "PXE-E32: TFTP open timeout" TFTP
| |
10:07 | i renamed the /opt/ltsp/i386 to /opt/ltsp/i386.backup and did a new ltsp-build-client, is that why the tftp cant load on the client?
| |
10:10 | <cliebow_> no
| |
10:10 | i have mixed results in pxe..depending on the card...
| |
10:11 | <writeout> http://paste.ubuntu-nl.org/55609/
| |
10:11 | is my dhcp conf invalid?
| |
10:11 | in /etc/ltsp/dhcp.conf
| |
10:18 | elisboa has quit IRC | |
10:21 | bobby_C has joined #ltsp | |
10:22 | elisboa has joined #ltsp | |
10:22 | <cliebow_> writeout, looks fine..
| |
10:22 | elisboa has quit IRC | |
10:23 | <writeout> tnx
| |
10:23 | trying to remove everything with ltsp and dhcp and tftp and try again
| |
10:25 | bobby_C has quit IRC | |
10:39 | staffencasa has joined #ltsp | |
10:47 | FuriousGeorge has quit IRC | |
10:48 | ogra_cmpc has joined #ltsp | |
10:48 | plamengr has joined #ltsp | |
10:50 | sutula has quit IRC | |
10:50 | jbrett has quit IRC | |
10:58 | Q-FUNK has quit IRC | |
10:59 | Q-FUNK has joined #ltsp | |
11:13 | ogra_cmpc has quit IRC | |
11:15 | ogra_cmpc has joined #ltsp | |
11:17 | Q-FUNK has quit IRC | |
11:19 | sutula has joined #ltsp | |
12:11 | Q-FUNK has joined #ltsp | |
12:13 | Topslakr| has quit IRC | |
12:14 | Blinny has joined #ltsp | |
12:16 | moldy has joined #ltsp | |
12:18 | moldy_ has joined #ltsp | |
12:20 | moldy has quit IRC | |
12:21 | moldy_ is now known as moldy | |
12:27 | Q-FUNK has quit IRC | |
12:36 | vagrantc has joined #ltsp | |
12:38 | slidesinger has quit IRC | |
12:38 | K_O-Gnom has quit IRC | |
12:40 | Q-FUNK has joined #ltsp | |
12:43 | indradg has joined #ltsp | |
12:57 | slidesinger has joined #ltsp | |
12:59 | writeout has quit IRC | |
12:59 | moldy has quit IRC | |
13:01 | gonzaloaf_laptop has joined #ltsp | |
13:05 | <Blinny> In LTSP5, lts.conf defaults to /var/lib/tftpboot/i386 or some such right? - I suppose the SERVER line is then removed from lts.conf and if you have multiple LTSP subnets then they're all served from one lts.conf ?
| |
13:06 | <vagrantc> if you don't specify the SERVER line in lts.conf, then it sets SERVER to whereever the root filesystem is mounted from.
| |
13:07 | moldy has joined #ltsp | |
13:07 | <vagrantc> so i would generally recommend not specifying SERVER
| |
13:07 | vagrantc has quit IRC | |
13:08 | lns has joined #ltsp | |
13:13 | vagrantc has joined #ltsp | |
13:17 | <Gadi> vagrantc: see my email to ltsp-dev?
| |
13:17 | <Blinny> Thanks vagrantc
| |
13:19 | <vagrantc> Gadi: yes
| |
13:19 | Gadi: haven't reviewed the branch yet, but most of it sure sounds good.
| |
13:20 | moldy has quit IRC | |
13:21 | <Gadi> vagrantc: Im looking forward to another set of eyes
| |
13:21 | :)
| |
13:22 | vagrantc: what happened to the rc.d scripts in the new ldm-trunk?
| |
13:22 | <vagrantc> Gadi: there was something relating to ssh -X and LDM_DIRECTX which i think might not be right ... because the ltspfs scripts actually need access to the X server ...
| |
13:22 | <Gadi> I don't see where they moved to
| |
13:22 | <vagrantc> Gadi: all of the non-ltspfs ones were removed, and all of the ltspfs ones were moved to ltspfs
| |
13:22 | <Gadi> vagrantc: I think I kept it for the sentinel connection but not the session connection
| |
13:25 | Q-FUNK has quit IRC | |
13:25 | plamengr has quit IRC | |
13:39 | <warren> did Edubuntu make a terminal server LiveCD?
| |
13:42 | Patina_ has joined #ltsp | |
13:42 | Patina_ has quit IRC | |
13:52 | <vagrantc> warren: i think it was attempted, but wasn't fast enough or something
| |
14:04 | jbrett has joined #ltsp | |
14:09 | <Gadi> ogra: have you already made a debian/ dir for ldm-trunk? or should I just copy and modify the bits from the gutsy ltsp pkg?
| |
14:11 | indradg_ has joined #ltsp | |
14:18 | Gato has joined #ltsp | |
14:18 | <Gato> Can someone help to connect by remote desktop using ubuntu server 7.10 + LTSP? the problem is when i put rdp_options = 192 168.1.2 screen_02 = rdesktop in lts.conf don't work, then sreen stil in black
| |
14:19 | <vagrantc> Gadi: is rdesktop installed in your chroot ?
| |
14:19 | <cliebow_> 8~)
| |
14:19 | <Gato> how can i see it?
| |
14:19 | <cliebow_> Gato:listen top vagrantc
| |
14:20 | <Gato> Where is chroot?
| |
14:20 | <cliebow_> Gato:how a bout sudo chroot /opt/ltsp/i386 && apt-get install rdesktop..then ltsp-update-image
| |
14:20 | <Gato> oki!
| |
14:21 | thanks a lot
| |
14:21 | <cliebow_> dont quote me...
| |
14:21 | K_O-Gnom has joined #ltsp | |
14:29 | indradg has quit IRC | |
14:30 | <Gadi> vagrantc: in some, yes
| |
14:30 | :)
| |
14:30 | <vagrantc> oops.
| |
14:32 | Blinny has quit IRC | |
14:35 | Gato_ has joined #ltsp | |
14:37 | <warren> grr
| |
14:37 | We don't call the arch 'amd64'
| |
14:37 | now how to fix this in a dist-neutral way...
| |
14:41 | Gadi has left #ltsp | |
14:42 | <vagrantc> warren: honestly, i think this is exactly the case for plugins
| |
14:43 | <warren> vagrantc, good point
| |
14:43 | <vagrantc> warren: in fact, i replied but never sent the email ...
| |
14:43 | <warren> vagrantc, i'd rather not add another file when it is just a tiny thing in common though.
| |
14:43 | vagrantc, do you have a x86_64 Debian system?
| |
14:44 | does Debian internally name it amd64?
| |
14:44 | when you type "arch"?
| |
14:44 | <vagrantc> warren: no idea...
| |
14:44 | i have no amd64 systems to test on
| |
14:45 | warren: we've been using dpkg --print-architecture, which has it's own logic... and i think for debian-derived systems, that's the smart thing to do.
| |
14:45 | * sutula volunteers that it is amd64 on Debian | |
14:46 | <warren> sutula, when you run "arch" it says amd64?
| |
14:46 | * sutula tries | |
14:46 | <vagrantc> warren: arch returns i686 on my machine, but there is no "i686" architecture for debian.
| |
14:46 | warren: i'm running the i386 architecture ...
| |
14:46 | <sutula> warren: Sorry...it returns x86_64
| |
14:46 | <warren> hmm
| |
14:46 | <vagrantc> warren: just sent the email.
| |
14:48 | <sutula> ...yet Debian commonly calls it amd64
| |
14:49 | <vagrantc> basically, i think debian-derived distros should use the debian related tools for architecture, since it doesn't really correlate to the .... libc6? gcc? ?? conception of architecture
| |
14:51 | Gato has quit IRC | |
14:51 | <sutula> fwiw, there is no /bin/arch on my desktop (unstable) machine...but there was one on my Etch/amd64
| |
14:52 | * sutula heads to a meeting | |
14:52 | <cliebow_> ogra:anything i should watch for with alternate cd??
| |
14:52 | Guaraldo has left #ltsp | |
14:57 | gonzaloaf_laptop has quit IRC | |
15:08 | K_O-Gnom has quit IRC | |
15:11 | gonzaloaf_laptop has joined #ltsp | |
15:23 | mikkel has quit IRC | |
15:23 | joebaker has joined #ltsp | |
15:28 | Gato_ has quit IRC | |
15:28 | makghosh has quit IRC | |
15:29 | cesar_ has joined #ltsp | |
15:29 | <vagrantc> oh gadi ...
| |
15:29 | <cesar_> hello people
| |
15:29 | one question
| |
15:30 | when the terminal is loading the system
| |
15:30 | not load the module for sound in the cliente
| |
15:30 | client
| |
15:31 | the module is "cmpci"
| |
15:31 | how I can install this module in the server if is necesary?
| |
15:32 | or...... what is happend?
| |
15:32 | cliebow_ has quit IRC | |
15:32 | <cesar_> when I execute a file .mp3 in xmms in the terminal client
| |
15:33 | the sound is playing in the server
| |
15:34 | in the client terminal shell I excecute this command
| |
15:34 | pci_scan /etc/audiolist
| |
15:34 | and I get "cmpci" for response
| |
15:35 | IsleVegan has joined #ltsp | |
15:35 | <cesar_> may be I need install a module "cmpci" in the server ltsp?
| |
15:36 | <vagrantc> cesar_: what linux distro and what release?
| |
15:36 | <cesar_> Debian ltsp 2.6.18-5-amd64
| |
15:37 | ltspcfg - Version 0.16
| |
15:37 | ltspadmin - v0.17
| |
15:38 | ltsp-utils 0.25-1
| |
15:38 | <vagrantc> cesar_: and you aren't using ltsp-server, right?
| |
15:39 | cesar_: ltsp-server and ltsp-utils are incompatible... so you need to make sure you only use one.
| |
15:39 | <cesar_> yes
| |
15:39 | only ltsp-utils is installed
| |
15:40 | in my Debian
| |
15:40 | ps ax|grep lts
| |
15:40 | <vagrantc> !sound
| |
15:40 | <ltspbot> vagrantc: "sound" is http://wiki.ltsp.org/twiki/bin/view/Ltsp/Sound
| |
15:40 | <cesar_> Ss 0:00 avahi-daemon: running [ltsp.local]
| |
15:40 | ok...
| |
15:41 | but I see the wiki page and I can't resolve the problem
| |
15:41 | <vagrantc> cesar_: it sounds like your environment variables for remote sound aren't set
| |
15:42 | <cesar_> one moment
| |
15:42 | in lts.conf
| |
15:42 | this is the set properties
| |
15:42 | SOUND = Y
| |
15:42 | SMODULE_01 = cmpci
| |
15:43 | SOUND_DAEMON = esd
| |
15:43 | VOLUME = 100
| |
15:43 | and any more
| |
15:43 | <vagrantc> ok, so that sounds good.
| |
15:44 | <cesar_> in the mailing lists and other page is similar configuration
| |
15:44 | but
| |
15:44 | when the terminal is loading modules
| |
15:44 | say
| |
15:44 | "FATAL: Module sound mcpci is not found"
| |
15:45 | <vagrantc> cesar_: mcpci, or cmpci ?
| |
15:45 | <cesar_> "it isn't loaded"
| |
15:45 | sorry
| |
15:45 | "cmpci"
| |
15:46 | this is the correct
| |
15:46 | :-)
| |
15:46 | it's write in lts.conf
| |
15:46 | but not working
| |
15:46 | <vagrantc> ok, so it doesn't have the cmpci module ...
| |
15:46 | Q-FUNK has joined #ltsp | |
15:46 | <vagrantc> which means your sound isn't going to work
| |
15:47 | <cesar_> yes
| |
15:47 | how I can get the module
| |
15:47 | <vagrantc> cesar_: so either you need to make sure that "cmpci" is the correct module name for the version of ltsp that you are using.
| |
15:47 | <cesar_> or how I can install this module in the server
| |
15:47 | <vagrantc> cesar_: or, you need to build the cmpci module for the kernel you're using for ltsp.
| |
15:48 | <cesar_> this module need stay in /opt/ltsp/i386....
| |
15:48 | <vagrantc> cesar_: how do you know it's "cmpci" ?
| |
15:49 | <cesar_> because lspci in terminal say the next information
| |
15:49 | one minute
| |
15:50 | C-Media Electronics CM8738
| |
15:50 | this is the result for do "lspci" in the terminal computer
| |
15:50 | and searching in the web
| |
15:51 | <Q-FUNK> ogra?
| |
15:51 | <cesar_> "cmpci" is the name
| |
15:51 | for the module
| |
15:51 | <vagrantc> cesar_: when you search on the web, did you find information specific to the version of ltsp you're using?
| |
15:51 | <cesar_> mmm... I am not be sure
| |
15:52 | ok
| |
15:53 | vagrantc : thanks for your help
| |
15:53 | <vagrantc> you need to find the module name for the specific kernel version you're using... ltsp 4.2 hasn't been updated in a long time. the module name may have changed since then.
| |
15:53 | <cesar_> I am going to have english class now... am late
| |
15:55 | tomorrow I try with your advice
| |
15:55 | ok thanks for all
| |
15:56 | bye..
| |
15:56 | <warren> vagrantc, I'm not so sure about a plugin for the arch issue
| |
15:56 | vagrantc, it is only one distro-specific line in 001-set-arch
| |
15:56 | vagrantc, there has to be a sane way to conditionalize that
| |
15:56 | <cesar_> tomorrow I will connect at this channel
| |
15:57 | :-)
| |
15:57 | <jammcq> warren: how about a simple translation
| |
15:57 | <warren> jammcq, in what way?
| |
15:57 | cesar_ has quit IRC | |
15:57 | <jammcq> well, I haven't seen the code
| |
15:57 | <warren> x86_64)
| |
15:57 | case "$(uname -m)" in
| |
15:57 | x86_64)
| |
15:57 | ARCH=amd64
| |
15:57 | ;;
| |
15:57 | <jammcq> but basically, if you have 'x86_64' and the system needs 'amd64'
| |
15:58 | yeah
| |
15:58 | <warren> jammcq, only Debian uses "amd64", we use x86_64
| |
15:58 | <jammcq> ok, then the other way around
| |
15:58 | I prefer x86_64 myself
| |
15:58 | amd64 is misleading
| |
15:58 | <warren> amd64 isn't even accurate, how do Intel users feel?
| |
15:58 | <jammcq> exactly
| |
15:58 | every time I build a new server, I look at that and think.... is this the one I need?
| |
15:58 | <Q-FUNK> there wasn't any emt64, at first
| |
15:59 | <jammcq> right, but did they think that amd was the ONLY 64-bit game in town?
| |
15:59 | <vagrantc> warren: yes, but it also likely applies to ppc vs. powerpc, and numerous other issues.
| |
15:59 | warren: look at the corresponding code in the debian plugin ...
| |
16:00 | <Q-FUNK> jammcq: alpha was already its own separate arch.
| |
16:00 | <warren> vagrantc, only a few lines?
| |
16:00 | <vagrantc> warren: much, much simpler than the common plugin
| |
16:00 | <warren> vagrantc, if Debian doesn't even use 001-setarch then why does the common plugin hardcode a Debianism?
| |
16:00 | <jammcq> Q-FUNK: i'm thinking in the x86 world. I know alpha and ppc and sparc have 64-bits
| |
16:01 | <vagrantc> warren: because it was written by people develping on debian and ubuntu?
| |
16:01 | <Q-FUNK> jammcq: there was no other x86 64-bit player for a while
| |
16:01 | <warren> OK, Ubuntu uses the common
| |
16:01 | <vagrantc> warren: we used it originally, but i got a bug report about unexpected behavior of amd64 installing i386, so i made a simpler version for debian.
| |
16:01 | <Q-FUNK> by the time intel reacted and came up with the emt64, it was already to late: the port was called amd64.
| |
16:01 | <warren> I remember those days.
| |
16:02 | We had to rebuild everything turning off two registers in the gcc compiler because EM64T was based on an earlier draft of the AMD64 spec.
| |
16:02 | So our x86_64 binaries became a least common denominator between the two archs.
| |
16:03 | Intel doesn't use EM64T anymore. They have some other silly name I thought?
| |
16:03 | anyway
| |
16:04 | <vagrantc> warren: i think the -set-arch code in common also made it impossible to install an amd64 ltsp environment, if i remember correctly.
| |
16:04 | * vagrantc continues to use the debianism term ... | |
16:10 | <warren> vagrantc, so debian relies entirely on the config option for arch being set
| |
16:10 | vagrantc, where is it set?
| |
16:10 | ogra has quit IRC | |
16:11 | ogra_cmpc has quit IRC | |
16:11 | ogra has joined #ltsp | |
16:11 | ogra_cmpc has joined #ltsp | |
16:24 | <vagrantc> warren: in debian's 000-basic-configuration plugin
| |
16:24 | IsleVegan has quit IRC | |
16:25 | nicoAMG has quit IRC | |
16:25 | <vagrantc> warren: that sets the defaults, and then all later plugins override the defaults
| |
16:25 | <warren> ahh
| |
16:26 | vagrantc, any suggestion how I can make it install a i386 chroot by default even on x86_64 unless overridden by a config option?
| |
16:26 | vagrantc, how are command line config options supposed to work?
| |
16:26 | vagrantc, ltsp-build-client --arch x86_64 ?
| |
16:27 | <vagrantc> warren: sure.
| |
16:27 | warren: i think the common/001-set-arch is ridiculously overcomplicated
| |
16:27 | <ogra_cmpc> lets just default to i386 in any case ?
| |
16:27 | * ogra_cmpc wouldnt mind that as a default | |
16:28 | <ogra_cmpc> evening btw
| |
16:28 | <warren> h
| |
16:28 | hi
| |
16:28 | <ogra_cmpc> :)
| |
16:29 | having a proper powerpc build through quemu is utopic for the next two years imho ....
| |
16:29 | amd64 clients are rare ...
| |
16:29 | so defaulting to x86 in any case with optional overrides seems sane
| |
16:29 | <vagrantc> amd64 clients are no rarer than the amd64 architecture ...
| |
16:30 | <warren> I'm going to default to i386 for x86_64 servers
| |
16:30 | and ppc for ppc64
| |
16:30 | they can override easily if they want
| |
16:30 | <ogra_cmpc> i have supported exactly one user who had amd64 cklients in my whole time in ltsp land
| |
16:31 | warren, my prob is that i provide CD installs .... so i need to have an option for it in any case
| |
16:31 | <vagrantc> ogra_cmpc: it is trivial to write an ubuntu plugin for it
| |
16:31 | <ogra_cmpc> on amd64 CDs we dont provide x86 poackages at all
| |
16:32 | vagrantc, i know, i'm still not eager to go through all the wikipages etc and fix the documented options we sue since ages
| |
16:32 | s/sue/use
| |
16:32 | <warren> ogra_cmpc, your AMD64 CD is of limited usefulness on its own anyway
| |
16:32 | ogra_cmpc, given what most clients are...
| |
16:32 | <ogra_cmpc> right
| |
16:32 | but it needs to work :)
| |
16:32 | jammcq has quit IRC | |
16:32 | <warren> so again, not a big issue
| |
16:33 | <ogra_cmpc> which forces me to have that option
| |
16:33 | <vagrantc> ogra_cmpc: yes, but it would be easier to write logic sticking to the debian/ubuntu architecture namespace, overriding common/001-set-arch than to make common/001-set-arch work for all distros
| |
16:34 | <ogra_cmpc> well, then lets drop 001-set-arch from common ...
| |
16:34 | i see no point for it being a common plugin
| |
16:34 | * vagrantc thinks *most* distros will be able to use it | |
16:35 | <warren> Do *most* distros call it amd64?
| |
16:35 | <ogra_cmpc> no idea
| |
16:35 | but we called it like that for the last two years in ltsp
| |
16:35 | <warren> Given that glibc, uname, kernel all call it x86-64
| |
16:35 | x86_64 I mean
| |
16:35 | Debian isn't even using it anymore
| |
16:35 | <vagrantc> warren: what i mean is that *most* distros should be able to use the "uname -m" output, but debian-derived distros are better using their own architecture namespace.
| |
16:36 | warren: what do you mean debian isn't even using it?
| |
16:36 | <ogra_cmpc> warren, deboootstrap, dpkg and apt-get use it
| |
16:36 | <vagrantc> warren: there is no architecture called x86_64 on debian.
| |
16:36 | <ogra_cmpc> $ARCH is neither referring to kernel nor to libc ....
| |
16:37 | <warren> vagrantc, the common/ file
| |
16:37 | I meant that file
| |
16:37 | <ogra_cmpc> its an architecture option for the packaging systen
| |
16:37 | system
| |
16:37 | <warren> calm down, I meant that file isn't used by Debian
| |
16:37 | <ogra_cmpc> well, if we keep it in common it should work for us all
| |
16:38 | if it doent do that is should go from common
| |
16:38 | * vagrantc sees no reason for all plugins in common to have to work for everybody | |
16:38 | <ogra_cmpc> else i dont really understand the point of having a common namespace
| |
16:38 | <vagrantc> if it works for 8 out of 10 distros, chances are it's fine in common.
| |
16:38 | the distros that are freakish will just have to work around it, which is trivial to do.
| |
16:38 | <warren> ogra_cmpc, I don't think 001-set-arch makes sense in common given that it doesn't work on Fedora derivatives
| |
16:39 | vagrantc, are you calling us freakish? =)
| |
16:39 | <vagrantc> warren: no, i'm calling debian and ubuntu freakish
| |
16:39 | <ogra_cmpc> well, most distros will be a derivative of one of the participating distros now... whats the prob of linking to the plugins your parent provides ?
| |
16:40 | warren, well, then put it into the Fedora dir and i'll link to the debian one
| |
16:40 | <vagrantc> whatever. this is such a trivial issue.
| |
16:40 | <warren> case "$MODE" in
| |
16:40 | commandline)
| |
16:40 | add_option "arch" "`eval_gettext "set the target architecture"`" "advanced" "true"
| |
16:40 | ;;
| |
16:40 | configure)
| |
16:40 | if [ -n "$option_arch_value" ]; then
| |
16:40 | ARCH_OPT="$option_arch_value"
| |
16:40 | <ogra_cmpc> i just dont see a point in it being in common
| |
16:40 | * vagrantc doesn't see the point of dragging this out any longer | |
16:40 | <warren> vagrantc, if arch is set by command line option, will it still run the configure) part?
| |
16:41 | ogra_cmpc, I agree.
| |
16:41 | <vagrantc> warren: that's the point.
| |
16:41 | <warren> I mean...
| |
16:41 | configure)
| |
16:41 | if [ -n "$option_arch_value" ]; then
| |
16:41 | ARCH_OPT="$option_arch_value"
| |
16:41 | else
| |
16:41 | ARCH_OPT=$(uname -m | sed -e s/i.86/i386/ -e s/ppc.*/powerpc/)
| |
16:41 | fi
| |
16:41 | $option_arch_value can come from either the command line or an earlier plugin?
| |
16:41 | <vagrantc> if the --arch flag is set to something, then $option_arch_value will be set
| |
16:42 | <warren> ok thanks for verifying
| |
16:42 | <vagrantc> $option_*_value is what the add_commandline_option function sets
| |
16:42 | <ogra_cmpc> vagrantc, well, it breaks my current builds and i dont want to change it without talking it over, i agree it might be to much fuss about a small issue but i cant release without fixing it in any way
| |
16:42 | <vagrantc> ogra_cmpc: i thought you were in upstream freeze a while ago anyways?
| |
16:42 | <ogra_cmpc> vagrantc, wednesday
| |
16:43 | valentine freeze :P
| |
16:43 | vagrantc, do you plan to keep the 5.0.40 versioning for lenny ?
| |
16:44 | (so i dont get issues with MOM)
| |
16:45 | <vagrantc> ogra_cmpc: well, until an upstream releases with a newer version, i plan to keep that for ltsp 5.0.40~bzr* ... ldm is using 2:0.1~bzr* and ltspfs is using 0.5.0~bzr*
| |
16:46 | <ogra_cmpc> why the epoch for ldm ?
| |
16:46 | <vagrantc> if the mips and mipsel buildd's EVER build a new package for ldm or ltsp
| |
16:46 | <ogra_cmpc> lol
| |
16:46 | slidesinger has quit IRC | |
16:46 | <ogra_cmpc> ok, i'll put it to 2.x and blacklist it in MOM
| |
16:46 | <vagrantc> ogra_cmpc: because the version in the source is 0.1, though 0.1 has never yet been released, and when it was part of ltsp, it was 5.* ... so needed to use epoch
| |
16:47 | <ogra_cmpc> the 0.1 is nonsense imho
| |
16:47 | its actually the 2.x release series
| |
16:47 | we should fix that upstream
| |
16:47 | <vagrantc> well, we're stuck with the epoch in debian.
| |
16:48 | <ogra_cmpc> yeah, sad for you, i luckily dont have mips
| |
16:48 | <vagrantc> there's been no upstream release of ltsp, ltspfs or ldm since ltsp 4.2
| |
16:48 | so picking a good version string is a little challenging.
| |
16:49 | <ogra_cmpc> well, for ldm its the second iteration of the code, i think a 2.x version makews sense here
| |
16:49 | <vagrantc> basically, ltsp-client in lenny is broken
| |
16:49 | ogra_cmpc: i think originally, it was going to be called ldm2, version 0.1
| |
16:49 | <ogra_cmpc> i havent evemn had the time tio check whats broken yet
| |
16:49 | only did a review of the changes
| |
16:49 | <vagrantc> ogra_cmpc: i'magine our debian dirs are really out of sync
| |
16:50 | <ogra_cmpc> mine isnt even in bzr yet :/
| |
16:50 | * vagrantc glares a little | |
16:50 | <ogra_cmpc> i'll fix that with thi9s upload
| |
16:50 | <vagrantc> gadi's been asking where to find the debian dir for various things
| |
16:51 | * vagrantc grumbles about gadi's 8-feature monolithic patch | |
16:51 | <ogra_cmpc> apt-get source various-things
| |
16:51 | <Q-FUNK> make universe
| |
16:51 | <ogra_cmpc> i guess we wont be able to drop -X
| |
16:52 | consolekit (or rather ssh wont handle that)
| |
17:00 | * ogra_cmpc wonders what to do with https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/172459 | |
17:00 | <ogra_cmpc> i wonder why we hardcoded that
| |
17:01 | especially since that coede is from pere who never ever hardcodes anything
| |
17:02 | <warren> Oh yes. Can we PLEASE branch ldm?
| |
17:02 | ldm-trunk should forge ahead with incompatible changes.
| |
17:02 | ldm-oldversionnumber should we a branch to continue on the old version?
| |
17:02 | <vagrantc> warren: when there's a release ...
| |
17:03 | <warren> You don't necessarily need a release
| |
17:03 | "branch point"
| |
17:03 | <ogra_cmpc> there was someone who wanted to taske over maintenance of the ldm1 code
| |
17:03 | <warren> ogra_cmpc, what is ldm1?
| |
17:03 | the current ldm-trunk or the older python?
| |
17:03 | <ogra_cmpc> the python version
| |
17:03 | before the ldm2 rewrite we did last year
| |
17:04 | so imho the 2 should be somewhere in the naming scheme
| |
17:04 | <vagrantc> warren: why not just branch using the incompatible changes *you* want to do, and then propose to merge them into ldm-trunk and branch the old version then?
| |
17:05 | <ogra_cmpc> (preferably not directly attached to the name (i.e. ldm2) bit thats only my gut esthaethical feeling :))
| |
17:05 | * vagrantc is not eagre to break compatibility | |
17:05 | <ogra_cmpc> s/bit/but/
| |
17:05 | why would we do that ?
| |
17:05 | <warren> do what?
| |
17:05 | <ogra_cmpc> and at what level
| |
17:05 | break compatibility
| |
17:06 | <warren> ogra_cmpc, ldm as is is inadequate in many ways
| |
17:06 | <vagrantc> warren: and works fine in many ways ...
| |
17:06 | <warren> ogra_cmpc, for one, the current code can't work on fedora at all.
| |
17:06 | <ogra_cmpc> ??
| |
17:06 | <vagrantc> warren: i'm not a big fan of breaking compatibility without specific reasons to do so.
| |
17:06 | <ogra_cmpc> it just requires an ssh server
| |
17:06 | <warren> ogra_cmpc, locale -a outputs too many languages
| |
17:07 | <ogra_cmpc> whats the problem with it ?
| |
17:07 | <vagrantc> warren: so your asking to break compatibility doesn't really speak to anything ...
| |
17:07 | <ogra_cmpc> warren, well, then add a better query for the langs :)
| |
17:07 | i'm not opposed to steal the hack from gdm
| |
17:07 | <vagrantc> apparently ubuntu doesn't handle "Default" as a login session, either.
| |
17:08 | so it only works when manually selecting which session
| |
17:08 | <warren> I'll show it to you when I have something concrete in code
| |
17:09 | <vagrantc> also, from what eharrison was saying, ldm cuts the output from ldminfod off at about 205 lines of output ... and he's experienced where you get 205 locales, and no session types or load rating
| |
17:09 | erg.
| |
17:09 | what i *meant* to say was: apparently ubuntu doesn't handle "Default" as a login session, either.
| |
17:10 | Q-FUNK has quit IRC | |
17:10 | <vagrantc> gah!
| |
17:10 | what i *meant* to say was: apparently fedora doesn't handle "Default" as a login session, either.
| |
17:11 | <ogra_cmpc> heh
| |
17:12 | vagrantc, well, there isnt really a need for listing 205 locales
| |
17:12 | gdm has some hackish code to cut down the list
| |
17:12 | i was hpoing to find the time to integrate that since we started ldm2
| |
17:13 | but i didnt yet
| |
17:13 | <warren> ogra, gdm is completely rewriting it now
| |
17:13 | * vagrantc wonders about a submenu ... since most locale's are the form of LANGUAGE_COUNTRY | |
17:14 | <ogra_cmpc> in any case i have a patch that makes it reload after the first password failure ... this "three attempts to type in your pw" is even confusing me
| |
17:14 | warren, so its good i didnt steal it yet :) i'll wait for a proper variant then ;)
| |
17:15 | vagrantc, well, i'd prefer a more descriptive (and localized) list than just the native locale value ...
| |
17:15 | and we'll need to handle dmrc at some point
| |
17:15 | <vagrantc> indeed
| |
17:16 | <ogra_cmpc> also on my list since ages
| |
17:17 | mccann has quit IRC | |
17:26 | <ogra_cmpc> vagrantc, any opinion on https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/132397 ?
| |
17:27 | i'd like to add the listed fix
| |
17:28 | * ogra_cmpc wonders what to do with all these xen related bugs *sigh* | |
17:28 | Furlow has joined #ltsp | |
17:29 | <Furlow> hi is there anyway to set the default session to gnome-session instead of what is already the default. Im using ubuntu
| |
17:30 | <ogra_cmpc> sudo update-alternatives --config x-session-manager
| |
17:30 | that sets the system default
| |
17:30 | (run it on the server)
| |
17:31 | <Furlow> thanks
| |
17:34 | <ogra_cmpc> vagrantc, did i tell you, the mythbuntu guys wrote a mythtv kiosk plugin :)
| |
17:35 | <Furlow> it provide this message when i run that command "(/usr/bin/gnome-session). Nothing to configure." which is okay but when i try to login on a client it requires me to select the session and the default one isn't /usr/bin/gnome-session would there be anything else I can try.
| |
17:35 | <ogra_cmpc> now people can have a server with tv card in the basement and a fanless thin client with the player in the living room
| |
17:36 | Furlow, hmm, it uses the default system session, which release and ltsp version are that ?
| |
17:41 | <Furlow> ltsp-server-5.0.39 ltsp-server-standalone-5.0.39 ltspfs-0.5-0ubuntu2 ldm-5.0.39 ltsp-client-5.0.39 ltsp-client-core-5.0.39 ltspfsd-0.5-0ubuntu2
| |
17:41 | <ogra_cmpc> thats gutsy then, right ?
| |
17:41 | <Furlow> yeah
| |
17:42 | <ogra_cmpc> did you add anything to your lts.conf ?
| |
17:42 | <Furlow> yes I did let me get the output, im only using one client so far
| |
17:43 | <ogra_cmpc> i9fr its more than three lines use the pastebot
| |
17:43 | !pastebot
| |
17:43 | <ltspbot> ogra_cmpc: "pastebot" is The LTSP pastebot is at http://pastebot.ltsp.org. Please paste all text longer than a line or two to the pastebot, as it helps to reduce traffic in the channel. A link to the content will be pasted in the channel.
| |
17:45 | <ltsppbot> "Furlow" pasted "my lts.conf" (6 lines) at http://pastebot.ltsp.org/442
| |
17:45 | gonzaloaf_laptop has quit IRC | |
17:45 | sonjag has joined #ltsp | |
17:45 | <Furlow> there it is
| |
17:46 | <ogra_cmpc> no need for
| |
17:46 | SOUND=Y
| |
17:46 | LOCALDEV=Y
| |
17:46 | NBD_SWAP=N
| |
17:47 | these are the defaults anyway
| |
17:47 | <Furlow> okay
| |
17:47 | sonjag has left #ltsp | |
17:47 | sonjagonzalez has joined #ltsp | |
17:47 | <ogra_cmpc> beyond that i dont see a reason that should prevent the default session from being run
| |
17:47 | <Furlow> I was just experimenting although they don't do anything
| |
17:48 | <ogra_cmpc> all ldm (the display manager) does is execute /etc/X11/XSession on the server ...
| |
17:49 | which by default will execute what ever the alternatives system is set to
| |
17:49 | (should be gnome-session)
| |
17:50 | what do you get if you just supply username and password at the greeter and hit enter ?
| |
17:51 | gonzaloaf_laptop has joined #ltsp | |
17:53 | <Furlow> I will check that file and see if there is anything i can do, The problem is it does list metacity on the client and i selected to see if i get same results as the default session and I did so im guessing metacity is the default although it doen't list it with sudo update-alternatives --config x-session-manager and to your last question i get a blank screen and no flashing lights on my switch (indicating that no data is being s
| |
17:54 | * ogra_cmpc reads the last comment and looks at vagrantc | |
17:54 | <ogra_cmpc> :P
| |
17:55 | Furlow, the selection you made only applied to the session you logged in to ... it doesnt change the default
| |
17:55 | check /var/log/auth.log and the users ~/.xsession-errors
| |
17:56 | it should list some erros indicating whats wrong
| |
17:56 | <Furlow> I know that, but it happens as soon as i start up, i just selected it to see if it might be the problem
| |
17:56 | <vagrantc> Furlow: try creating a new user and seeing if they get the same broken session
| |
17:57 | ogra_cmpc: regarding blindly copying all /etc/apt/apt.conf* stuff over, i think it's a bad idea. there are *so many* possible settings there, that it's hard to guage which would be appropriate for the thin-client.
| |
17:57 | <ogra_cmpc> yeah, thats right
| |
17:58 | <vagrantc> ogra_cmpc: i think simply pointing out the use of the http_proxy environment variable, or maybe even a commandline option to set that variable would be better.
| |
17:58 | <ogra_cmpc> but i also thi9nk we're running on the same hardware with the same network
| |
17:58 | hmm
| |
17:59 | <vagrantc> ogra_cmpc: yes, but some packages drop files into /etc/apt/apt.conf.d/ and i'm not sure how they'd behave if their corresponding package wasn't installed
| |
17:59 | <ogra_cmpc> probably just a chec k if http_proxy is set and then export it in the client env
| |
17:59 | <vagrantc> ogra_cmpc: you mean, check the configuration files?
| |
18:00 | <ltsppbot> "Furlow" pasted "auth.log" (2 lines) at http://pastebot.ltsp.org/443
| |
18:01 | <vagrantc> looking for Acquire::http::proxy "foo"; is trivial, but it could also be in the Acquire configuration block, http::proxy "foo"; or maybe even Acquire block, and the http block within the Acquire block, and proxy "foo";
| |
18:02 | <Furlow> The lights on my switched blinked as i logged in that time and in auth.log it would show that it did get the password but does not indicate any x server crash
| |
18:04 | <ltsppbot> "Furlow" pasted "auth.log" (2 lines) at http://pastebot.ltsp.org/444
| |
18:04 | <Furlow> it uses a different port when selecting the gnome-session
| |
18:05 | alekibango has joined #ltsp | |
18:08 | <ltsppbot> "Furlow" pasted "~/.xsession-errors" (24 lines) at http://pastebot.ltsp.org/445
| |
18:08 | <Furlow> well that would explain
| |
18:08 | <vagrantc> warren: your new set-arch plugin looks like there's no possible way to install amd64 on amd64 ... is that intentional?
| |
18:10 | warren: the --arch x86_64 would still result in ARCH=i386
| |
18:11 | warren: er, x86_64 on x86_64 ...
| |
18:14 | <Furlow> would anyone know what i can do to fix my problem i you read my pastes
| |
18:15 | <ogra_cmpc> Furlow, sudo apt-get remove xserver-xgl
| |
18:15 | (its unsupported for a reason ;) )
| |
18:17 | <Furlow> I don't run a stand alone sever and I intend to use it to boost the performance of my laptop so will that remove my the desktop effects on the server machine
| |
18:18 | <ogra_cmpc> you intend to use the most cpu intensive variant of getting composite to work to boost your system performance ?
| |
18:18 | * ogra_cmpc scratches haed | |
18:19 | <Furlow> no
| |
18:19 | sorry bad wording
| |
18:19 | <ogra_cmpc> :)
| |
18:19 | well, xgl isnt integrated with ltsp in any way
| |
18:20 | afaik they use an xsession script in /etc/X11/Xsession.d
| |
18:20 | <Furlow> i mean i intend to use ltsp to boost my laptop performance and i wanted to know if "apt-get remove xserver-xgl" would remove the desktop effects on my server
| |
18:20 | <ogra_cmpc> you need to hack up that script to not start xgl if LTSP_CLIENT exists in the sessions environment
| |
18:22 | it will remove the xgl xserver ... depends what kind of graphics card you have, afaik xgl only helps wiht composit4e with a certain amount of ati cards ... for all other HW you should use the defauklt method ubuntu ships
| |
18:22 | <Furlow> hum it says its a directory, do open one of the scripts in that folder
| |
18:23 | <ogra_cmpc> well there should be a script with xgl in the filename
| |
18:23 | <Furlow> I got it
| |
18:23 | so what do i need to ass
| |
18:23 | add
| |
18:23 | sorry
| |
18:24 | <ogra_cmpc> nol idea, i dont know xgl :) just makwe sure it doesnt use the xgl server
| |
18:24 | <Furlow> Okies I will try and figure that out myself but thanks for help
| |
18:25 | <ogra_cmpc> i9'd really suggest not using xgl
| |
18:25 | <Furlow> is there an alternative i have ati by the way
| |
18:26 | <ogra_cmpc> well, ati either works with compiz in the default install (just check teh checkbox in teh settings)
| |
18:26 | <Furlow> surely you need xgl so compiz will work???
| |
18:26 | <ogra_cmpc> or you are one of the few souls that actually have one of the three or four cards that actually *need* xgl
| |
18:27 | <Furlow> I think that I am
| |
18:27 | i've had many great troubles with xgl and compiz and what not
| |
18:28 | <ogra_cmpc> well in any case fglrx (the ati binary driver) forces xgl ... if you use the free driver the majority of ati cards works out of the box
| |
18:28 | well, easy solution, use sane softwarer
| |
18:28 | (xgl doesnt belong in that realm)
| |
18:30 | the majority of cards should work without and extra software in ubuntu just by switching on the desktop effects
| |
18:32 | xgl actually runs a second xserver inside the running xorg server to get composite ... that means you always run two x servers
| |
18:32 | which indeed quite heavily eats your ressources
| |
18:39 | <Furlow> yeah i guess so, long time since i fiddled with xgl and im using fglrx, I will try to use the free driver, i think my problem stemed from needing higher resolutions and the card would not produce it with out fglrx that was with a crt and since then I have switch to a lcd i got second hand for free
| |
18:40 | <ogra_cmpc> ah
| |
18:41 | <Furlow> i guess it might just be easier to switch to nvidia form ati in the future which is what i will do
| |
18:41 | <ogra_cmpc> or get intel
| |
18:41 | sonjagonzalez has quit IRC | |
18:41 | <ogra_cmpc> (unless youre a heavy gamer or 3D professional)
| |
18:41 | <Furlow> yeah or intel which is what the laptop is
| |
18:42 | thanks for your help i have to go now
| |
18:42 | Furlow has left #ltsp | |
18:43 | joebaker has quit IRC | |
18:46 | gonzaloaf_laptop has quit IRC | |
18:49 | SteveWrightNZ has joined #ltsp | |
18:50 | <SteveWrightNZ> blank terminals after apt-get dist-upgrade - any hint ?
| |
18:50 | (ubuntu latest)
| |
18:51 | terminals boot, dont start X
| |
18:51 | <ogra_cmpc> latest meaning hardy or latest release ?
| |
18:51 | <SteveWrightNZ> how to tell ?
| |
18:51 | 7.10 gutsy
| |
18:51 | <ogra_cmpc> lsb_release -a
| |
18:51 | otavio has quit IRC | |
18:51 | <ogra_cmpc> ah
| |
18:52 | how exactly did you dist-upgrade ?
| |
18:53 | <SteveWrightNZ> using the GUI updater
| |
18:53 | "7.10 is available - do u wanna?" etc
| |
18:53 | <ogra_cmpc> well, that doesnt update the client environment at all
| |
18:53 | <SteveWrightNZ> k
| |
18:53 | <ogra_cmpc> it doesnt change anything in there
| |
18:53 | <SteveWrightNZ> so why it stop if from working then ?
| |
18:54 | update the chroot as well ?
| |
18:54 | <ogra_cmpc> no idea, how exactly does the screen look like if it finished booting ?
| |
18:54 | <SteveWrightNZ> black, blinking cursor
| |
18:54 | top left ;-)
| |
18:55 | <ogra_cmpc> so it properly boots...
| |
18:55 | thats the only thing that could have been influenced by a server upgrade
| |
18:55 | <SteveWrightNZ> yes it boots
| |
18:56 | then busybox pops up
| |
18:56 | after a few mins
| |
18:56 | <ogra_cmpc> you must have changed anything ... did you add any options to your lts.conf or so ?
| |
18:56 | <SteveWrightNZ> no
| |
18:56 | <ogra_cmpc> you said you egt a blinking cursor ...
| |
18:56 | <SteveWrightNZ> yes this is true
| |
18:56 | <ogra_cmpc> \now you say busybox pops up
| |
18:56 | <SteveWrightNZ> yes I did say that
| |
18:57 | <ogra_cmpc> so do you end up in a busybox or do you end up at a blinking cursor ?
| |
18:57 | * ogra_cmpc is confused | |
18:57 | <SteveWrightNZ> perhaps someone else has seen this fault
| |
18:58 | <ogra_cmpc> again ... how exactly does the screen look like if it *finished* booting
| |
18:58 | <SteveWrightNZ> (initramfs)_
| |
18:58 | <ogra_cmpc> do you have a busybox shell or not ?
| |
18:58 | ah
| |
18:58 | ok
| |
18:59 | did you get any questions about changed config files during the upgrade ?
| |
18:59 | <SteveWrightNZ> yes
| |
18:59 | <ogra_cmpc> do you remember the packages/files ?
| |
18:59 | staffencasa has quit IRC | |
19:00 | <SteveWrightNZ> it is quite likely the dist-upgrade overwrote a valid conf file
| |
19:00 | not really, but I would likely recall the names if I saw then again
| |
19:00 | I should have written this down but oh well
| |
19:00 | <ogra_cmpc> dhcpd.conf, inetd.conf would be relevant
| |
19:00 | <SteveWrightNZ> not those
| |
19:00 | dhcpd is working
| |
19:00 | as it booted
| |
19:01 | <ogra_cmpc> well, check if nbdrootd is still listed in inetd.conf
| |
19:01 | <SteveWrightNZ> ok
| |
19:01 | brb
| |
19:01 | <ogra_cmpc> thats responsible for the root fs
| |
19:01 | gonzaloaf has joined #ltsp | |
19:01 | <vagrantc> ogra_cmpc: commented on lp#132397 with some tricks that might be palatable
| |
19:02 | <ogra_cmpc> thanks :)
| |
19:02 | <SteveWrightNZ> ogra_cmpc: no it is not mentioned
| |
19:02 | gonzaloaf_laptop has joined #ltsp | |
19:02 | <vagrantc> not beautiful ...
| |
19:02 | <ogra_cmpc> SteveWrightNZ, oh, weird
| |
19:03 | SteveWrightNZ, 2000 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/i386.img
| |
19:03 | <SteveWrightNZ> ok trying
| |
19:03 | <ogra_cmpc> there should be this line
| |
19:04 | <SteveWrightNZ> done, inetd restarted, rebooting
| |
19:05 | black screen, blinking cursor
| |
19:05 | <ogra_cmpc> btw, you can drop splash and quiet from /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default to get more debugging info
| |
19:05 | <SteveWrightNZ> ah ok
| |
19:06 | aha
| |
19:06 | <ogra_cmpc> you should also see the nbd mount attempt in the daemon.log on the server
| |
19:06 | <SteveWrightNZ> NFS over TCP not available
| |
19:06 | <ogra_cmpc> gutsy doesnt use nfs
| |
19:06 | <SteveWrightNZ> /ltsp/i386/nbi.img
| |
19:06 | alt-F1
| |
19:07 | <ogra_cmpc> (at least not unless you enabled it manually with some effort)
| |
19:07 | <warren> vagrantc, are you sure?
| |
19:07 | <vagrantc> but if the chroot wasn't updated, it's still feisty or older, isn't it?
| |
19:07 | <SteveWrightNZ> this error loops continually on the terminal
| |
19:07 | chroot was not dist-update d
| |
19:07 | <vagrantc> warren: i am pretty sure.
| |
19:07 | <warren> oh
| |
19:07 | oops
| |
19:07 | <ogra_cmpc> vagrantc, hmm, right, i didt read dist/upgarde as distro upgarde
| |
19:08 | *dist-upgrade
| |
19:08 | warren, he's right
| |
19:08 | <SteveWrightNZ> chroot is stil fiesty
| |
19:09 | <ogra_cmpc> SteveWrightNZ, sudo mv /opt/ltsp/i386 /opt/ltsp/i386.feisty && sudo ltsp-build-client
| |
19:10 | <vagrantc> warren: the way the plugin is written, ARCH_OPT always gets set to something, and you have all cases of when ARCH_OPT is set to x86_64 to have it set ARCH=i386
| |
19:10 | <SteveWrightNZ> ok
| |
19:10 | <warren> yeah
| |
19:10 | I'm thinking how best to fix this.
| |
19:10 | so it is overridale
| |
19:10 | overrideable
| |
19:10 | <ogra_cmpc> put ARCH=i386 into the *) option :)
| |
19:10 | <SteveWrightNZ> sudo mv /opt/ltsp/i386 /opt/ltsp/i386.feisty && sudo ltsp-build-client // running now
| |
19:10 | <warren> ia64 makes no sense to be in that list.
| |
19:10 | * vagrantc didn't like that plugin code from the instant it was written | |
19:11 | <ogra_cmpc> and only override on ppc/x86_64
| |
19:11 | warren, ubuntu has an ia64 builld (and actually ltsp is working on that i heard)
| |
19:11 | <vagrantc> i sat there, looking over otavio's shoulder, saying ... this is a bad idea.
| |
19:12 | ogra_cmpc: does ia64 support i386 chroots ?
| |
19:12 | <warren> vagrantc, sort of
| |
19:12 | vagrantc, it is a complete mess
| |
19:12 | <ogra_cmpc> not by definition of our code, no
| |
19:12 | <vagrantc> no, i mean can you chroot to an i386 chroot on an ia64 architecture?
| |
19:12 | <warren> vagrantc, some ia64 has extra hardware to run i386, most ia64 lacks that hardware and intel wrote a binary-only emulation layer that lives in /emul/i386
| |
19:13 | <ogra_cmpc> vagrantc, but its a quick way to get a wroking netboot env ;)
| |
19:13 | <warren> vagrantc, but if it lives in /emu/i386 what happens if you run stuff in a chroot elsewhere? I don't know.
| |
19:13 | <vagrantc> so the sort answer is "not really"
| |
19:13 | <warren> vagrantc, the kernel has nasty hacks to sort of use /emul/i386 as if it were a root
| |
19:13 | <ogra_cmpc> i doubt you have much fun on an ia64 ltsp server anyway
| |
19:13 | <warren> yea
| |
19:13 | ia64 really sucks
| |
19:14 | gonzaloaf_laptop has quit IRC | |
19:14 | * vagrantc has been nudging to drop all arches but i386, amd64 and powerpc for debian's ltsp packages | |
19:14 | <ogra_cmpc> makes as much sense as having an s390 build
| |
19:14 | vagrantc, arm would make sense for debian i suppose
| |
19:15 | * ogra_cmpc would love to do/have arm support, but ubuntu doesnt support arm | |
19:15 | <vagrantc> ogra_cmpc: when we have tested netboot stuff for arm, i'd consider it
| |
19:16 | ogra_cmpc: right now the only netboot stuff that's tested is i386, powerpc and amd64 (and the latter two not very thoroughly tested), as well as untested code for sparc and alpha.
| |
19:16 | <ogra_cmpc> doesnt familiar have working netboot modes for arm ?
| |
19:16 | sparc works afaik
| |
19:17 | <vagrantc> sparc doesn't work at all with debian unstable or testing
| |
19:17 | <ogra_cmpc> fabio said so back in edgy/feisty some point
| |
19:17 | <vagrantc> well, not with the network booting used in initramfs-tools ...
| |
19:17 | <ogra_cmpc> i didnt hear any recent sparc info
| |
19:17 | <vagrantc> bugs in klibc-utils
| |
19:18 | <ogra_cmpc> well, ubuntu supports sparc and we have a netinstall image
| |
19:18 | so it must work somehow with our initramfs
| |
19:18 | s/supports/supported (we dont anymore afaik)
| |
19:18 | <vagrantc> ogra_cmpc: well, debian-installer netinstall probably uses dhcp3-client instead of ipconfig from klibc-utils
| |
19:19 | <ogra_cmpc> oh, right, that might be
| |
19:19 | <vagrantc> ogra_cmpc: so i hacked around ipconfig ... and then nfsmount from klibc-utils also broke ...
| |
19:19 | ogra_cmpc: maybe it would work with nbd
| |
19:20 | <ogra_cmpc> just use mount
| |
19:20 | <vagrantc> well, mount doesn't work for nfs mounts from the initramfs eitehr
| |
19:20 | tried that
| |
19:20 | <ogra_cmpc> huh ?
| |
19:20 | <vagrantc> yup
| |
19:20 | <ogra_cmpc> i used it in ltsp before
| |
19:20 | <vagrantc> so have i
| |
19:20 | but the versions in sid don't work
| |
19:20 | <ogra_cmpc> weird
| |
19:21 | <vagrantc> they give some error about looking for /sbin/mount.nfs ... which doesn't exist on the server which can do nfs mounts using /bin/mount
| |
19:21 | <ogra_cmpc> ah
| |
19:22 | <SteveWrightNZ> why couldn't have done sudo chroot /opt/ltsp/i386 && apt-get dist-upgrade ?
| |
19:22 | <ogra_cmpc> vagrantc, add nfs/common to your initramfs :)
| |
19:22 | grr
| |
19:23 | <vagrantc> ogra_cmpc: nfs-common ?
| |
19:23 | <ogra_cmpc> why do you english guys just have to change all key positions
| |
19:23 | yeah
| |
19:23 | thats where mount.nfs lives
| |
19:23 | <warren> ogra, ASCII begins with American =)
| |
19:23 | <ogra_cmpc> pfft
| |
19:23 | <vagrantc> ogra_cmpc: but it's not even needed ...
| |
19:24 | <ogra_cmpc> warren, no reason to change y and z or / and -
| |
19:24 | vagrantc, i think mount requires such stuff nowadays
| |
19:25 | <vagrantc> ogra_cmpc: ah, you're right ... it's there. ok ... i'll give sparc a couple more tries.
| |
19:25 | <warren> ogra_cmpc, the QWERTY layout was an arbitrary layout designed to slow down typing so the keys of the typewriter wouldn't get stuck together as people typed too fast.
| |
19:25 | <ogra_cmpc> hehe, really ?
| |
19:25 | <warren> ogra_cmpc, yeah. My mom has one of those old typewriters. If I type too fast they get stuck
| |
19:25 | <vagrantc> ogra_cmpc: altough really... having to hack the initramfs to use dhcp3-client and /bin/mount and /sbin/mount.nfs ... not my idea of fun
| |
19:25 | but i guess that would at least be useful troubleshooting feedback
| |
19:26 | <ogra_cmpc> warren, well, i have such a thing here as well, but i didnt know there was a case in human history that early already where usability workarounds tried to overcome hardware issues
| |
19:27 | i wouldnt have tought that was the reason for the layout :)
| |
19:27 | <vagrantc> that's just dvorak conspiracy theorists.
| |
19:28 | * ogra_cmpc always tought layouts were defined by the frequency a letter shows up in a language | |
19:28 | * vagrantc notes that it is based on frequency... just not necessarily in the way you might think | |
19:28 | <ogra_cmpc> vagrantc, well, its only a special hook for sparc, you dont need to copy iy into a normal one :)
| |
19:29 | <warren> ogra_cmpc, it was designed so you wouldn't type keys that are close together so they don't get stuck
| |
19:31 | joebaker has joined #ltsp | |
19:32 | spectra has quit IRC | |
19:33 | gentgeen__ has quit IRC | |
19:34 | <vagrantc> well, i just pushed the ldm guest login button patches to ldm... hopefully now i can say goodbye to sdm! :)
| |
19:36 | <ogra_cmpc> youre becoming a C coder eh ? :)
| |
19:36 | <vagrantc> ogra_cmpc: no, Ryan52 has been rocking it out!
| |
19:36 | ogra_cmpc: i mean, i'm a better C patcher than i was
| |
19:37 | between a few ldm and ltspfs patches, i'm slowing moving beyond totally clueless
| |
19:38 | <ogra_cmpc> ah, well, your patches looked quite sane
| |
19:39 | <vagrantc> but most of the heavier work has been done by Ryan52
| |
19:39 | <ogra_cmpc> you will need the consolekit changes to openssh for the recent gnome btw
| |
19:40 | <vagrantc> ogra_cmpc: what's recent?
| |
19:40 | <ogra_cmpc> not sure if colin applied them to debian and synced tha6t
| |
19:40 | the current dev version
| |
19:40 | <vagrantc> looking at a few stages of freeze over the next few months
| |
19:40 | <ogra_cmpc> (2.21 ... upcoming 2.22 release)
| |
19:40 | lenny will likely have 2.20
| |
19:41 | but for sid you'll need it
| |
19:41 | <vagrantc> currently 2.20 in unstable, 2.14 in lenny ...
| |
19:41 | <ogra_cmpc> woah, really ?
| |
19:41 | 2.14 is ages old
| |
19:43 | <vagrantc> ogra_cmpc: looks like it hasn't ever migrated from sid to lenny ... it's the same version that's in etch
| |
19:43 | <ogra_cmpc> are you sure its 2.14 ?
| |
19:43 | oh
| |
19:43 | thats bitter
| |
19:44 | a new release with the same old desktop software is a bad idea
| |
19:44 | <vagrantc> i'magine it'll make it to 2.20
| |
19:45 | <ogra_cmpc> depending on your freezes
| |
19:47 | <vagrantc> there's a few RC bugs, and some slow buildd's ...
| |
19:48 | <ogra_cmpc> i thought the slow arches would be ignored now
| |
19:48 | <vagrantc> i don't think any architecture re-qualification has happened yet ...
| |
19:48 | <ogra_cmpc> intresting ...
| |
19:49 | i remember when it was discussed 2 years ago when elmo went to that special ftpmasters meeting
| |
19:50 | 2 years and still no change is quite slow ...
| |
19:50 | * ogra_cmpc noticed today that ian murdoc seems to work for sun now ... | |
19:51 | <ogra_cmpc> doing opensolaris desktop integration
| |
20:08 | <SteveWrightNZ> I: Retrieving startup-tasks ## stuck here why ?
| |
20:20 | <jcastro> warren: around?
| |
20:20 | <warren> jcastro, what's up?
| |
20:25 | rjune has quit IRC | |
20:33 | joebaker has quit IRC | |
20:35 | joebaker has joined #ltsp | |
20:55 | <warren> case "$ARCH_OPT" in
| |
20:55 | i386)
| |
20:55 | case "$(uname -m)" in
| |
20:55 | x86_64|ia64|i386|i486|i586|i686)
| |
20:55 | ARCH=i386
| |
20:55 | ;;
| |
20:55 | esac
| |
20:55 | this part actually doesn't make sense
| |
20:56 | It is *possible* to install a i386 chroot on ppc host with qemu.
| |
20:56 | qemu can be either a full VM or process-level VM
| |
21:01 | joebake1 has joined #ltsp | |
21:02 | joebaker has quit IRC | |
21:06 | jammcq has joined #ltsp | |
21:06 | <SteveWrightNZ> hello Jim
| |
21:07 | <jammcq> hey SteveWrightNZ, how's it goin?
| |
21:07 | <SteveWrightNZ> good good, and how are you ?
| |
21:07 | Ubuntu+LTSP is very good now
| |
21:08 | <jammcq> yeah, they've done a fantastic job
| |
21:08 | and i'm doing well. mostly watching the development these days
| |
21:08 | <SteveWrightNZ> the old days of attaching scanners with hammer and saw are over
| |
21:08 | ok
| |
21:09 | how are the k12ltsp lads doing ?
| |
21:09 | <warren> SteveWrightNZ, working on it
| |
21:09 | <jammcq> umm, well, I guess
| |
21:09 | <warren> SteveWrightNZ, i'm the only one working on it, been hampered by health problems
| |
21:09 | <SteveWrightNZ> hi warren
| |
21:09 | oh thats not so good
| |
21:09 | <jammcq> warren: are you working on anything other than ltsp integration?
| |
21:09 | <warren> jammcq, yes, a few other unrelated things unfortunately
| |
21:10 | <jammcq> hmm
| |
21:10 | <warren> jammcq, and our mkinitrd and chroot install problems have been much larger than I thought.
| |
21:10 | jammcq, it turns out that nobody else has anything like my problem
| |
21:10 | pieces are finally falling together now though.
| |
21:10 | <SteveWrightNZ> does FC slide together with LTSP as well as Ubuntu does ?
| |
21:11 | <warren> SteveWrightNZ, it will by Fedora 9
| |
21:11 | <SteveWrightNZ> nice
| |
21:11 | <warren> SteveWrightNZ, currently due to be released late April
| |
21:11 | <jammcq> warren: cool. keep chipping away at it, and eventually it'll look great
| |
21:11 | <SteveWrightNZ> nice
| |
21:13 | oh207 has quit IRC | |
21:13 | oh207 has joined #ltsp | |
21:22 | joebake1 has quit IRC | |
21:22 | joebaker has joined #ltsp | |
21:42 | <vagrantc> warren: all you need now is one more "
| |
21:43 | - [ "$ARCH_OPT" == "x86_64 ] && ARCH_OPT=i386
| |
21:43 | + [ "$ARCH_OPT" == "x86_64" ] && ARCH_OPT=i386
| |
21:46 | <MacIver> that is soo evil
| |
21:47 | * vagrantc grins | |
21:49 | <vagrantc> "LTSP: go ahead and be evil, the rest is allegedly google's motto"
| |
21:50 | <MacIver> took me about 30 seconds to see wtf that was doing :-p
| |
22:12 | Joris_ has joined #ltsp | |
22:12 | <SteveWrightNZ> after ltsp-build-client I get a black screen on the terminal with blinking cursor.. any hint ?
| |
22:12 | Ubuntu 7.10
| |
22:15 | <MacIver> ltsp-update-*
| |
22:22 | oh207 has quit IRC | |
22:25 | <SteveWrightNZ> thx
| |
22:28 | Joris has quit IRC | |
22:35 | rjune has joined #ltsp | |
22:40 | subir has joined #ltsp | |
22:41 | <SteveWrightNZ> MacIver: no change
| |
22:41 | joebaker has quit IRC | |
22:42 | <SteveWrightNZ> TFTTP: File not found /ltsp/i386/lts.conf
| |
22:47 | <MacIver> weird error
| |
22:47 | did you get any errors from the build?
| |
22:47 | <SteveWrightNZ> a few warnings
| |
22:47 | but hard to tell what is fatal or not
| |
22:47 | also, there is no lts.conf
| |
22:48 | well, there is but it has one line in it
| |
22:48 | [default]
| |
22:48 | LTSP_VERSION=5.0.39
| |
22:51 | <MacIver> hmm, i'm no ltsp expert...i have only used it on edubuntu so far :-p
| |
22:51 | <SteveWrightNZ> the terminal does its IP-Config
| |
22:51 | then just says ltsp login:
| |
22:51 | <MacIver> does it get the kernel image?
| |
22:51 | <SteveWrightNZ> yes it boots fine
| |
22:51 | <MacIver> oh, so it does have the login prompt?
| |
22:51 | <SteveWrightNZ> yes
| |
22:51 | just no X
| |
22:51 | <MacIver> it's just that ldm is not starting?
| |
22:51 | <SteveWrightNZ> so it seems yes
| |
22:52 | lts.conf has no config in it
| |
22:52 | is this correct ?
| |
22:52 | <MacIver> that should be ok
| |
22:52 | <SteveWrightNZ> there is also an error "unknown keyword in config file"
| |
22:53 | before loading vzlinuz
| |
22:53 | vmlinuz
| |
22:54 | <MacIver> probably that LTSP_VERSION part... i never saw that as a lts option :-p
| |
22:54 | which makes me wonder where that file came from...
| |
22:54 | <SteveWrightNZ> agreed
| |
22:54 | ltsp 5 lts.conf file where to get one from ?
| |
22:55 | with no lts.conf file it seems that should be resolved.. no ?
| |
22:55 | in the past, that was the heart of the terminal config
| |
22:55 | <MacIver> on edubuntu it didn't come with one, but i could create my own if needed
| |
22:55 | <SteveWrightNZ> but usually not needed ?
| |
22:56 | <MacIver> not unless you are needing to set non-default, or machine specific settings
| |
22:56 | <SteveWrightNZ> ok I will ignore this then
| |
22:59 | can I log onto the running terminal image ?
| |
23:01 | <MacIver> you can if you add yourself as a user
| |
23:14 | <SteveWrightNZ> adduser in the chroot ?
| |
23:16 | that didnt work.. rebooting..
| |
23:17 | how can a simple dist-upgrade go this wrong ?
| |
23:27 | <MacIver> you need to adduser and the ltsp-update-image
| |
23:32 | <SteveWrightNZ> oh
| |
23:32 | I'm going to retry sudo ltsp-build-client
| |
23:47 | <vagrantc> SteveWrightNZ: you dist-upgraded from what to what?
| |
23:47 | <SteveWrightNZ> fiesty to gutsy
| |
23:48 | 7.04 to 7.1
| |
23:48 | and I am left with a screaming heap
| |
23:48 | or is it a steaming pile ?
| |
23:48 | server is fine
| |
23:49 | terminals boot but no X
| |