|00:00||map7 has joined IRC (email@example.com)|
|00:28||risca has joined IRC (firstname.lastname@example.org)|
|01:22||vagrantc has left IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net, Ping timeout: 260 seconds)|
|02:29||Parker955_Away is now known as Parker955|
|02:35||risca has left IRC (email@example.com, Quit: Lämnar)|
|03:10||Parker955 is now known as Parker955_Away|
|03:10||josh has left IRC (firstname.lastname@example.org, Disconnected by services)|
|03:11||zevlag has joined IRC (email@example.com)|
|04:02||zevlag has left IRC (firstname.lastname@example.org, *.net *.split)|
|04:02||cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, *.net *.split)|
|04:04||andygraybeal_ has left IRC (email@example.com, Ping timeout: 240 seconds)|
|04:06||zevlag has joined IRC (firstname.lastname@example.org)|
|04:06||cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)|
|04:52||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|05:09||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|05:21||srdjo has joined IRC (email@example.com)|
|08:12||loather has left IRC (firstname.lastname@example.org, Quit: This computer has gone to sleep)|
|09:02||komunista has joined IRC (email@example.com)|
|09:09||monteslu has left IRC (firstname.lastname@example.org, Ping timeout: 255 seconds)|
|09:21||khildin has joined IRC (email@example.com)|
|09:21||monteslu has joined IRC (firstname.lastname@example.org)|
|11:15||mikkel has joined IRC (email@example.com)|
|11:43||srdjo_ has joined IRC (firstname.lastname@example.org)|
|11:44||srdjo has left IRC (email@example.com, Ping timeout: 252 seconds)|
|11:52||NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 245 seconds)|
|12:12||DIoX|DaZ has left IRC (DIoX|DaZ!~KaKa@server.civicclub.lt, Ping timeout: 260 seconds)|
|12:14||DIoX|DaZ has joined IRC (DIoX|DaZ!~KaKa@server.civicclub.lt)|
|13:14||TatankaT_ has joined IRC (TatankaT_firstname.lastname@example.org)|
|13:14||shawnp0w1rs has joined IRC (email@example.com)|
|13:19||monteslu has left IRC (firstname.lastname@example.org, *.net *.split)|
|13:19||TatankaT has left IRC (TatankaTemail@example.com, *.net *.split)|
|13:19||shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, *.net *.split)|
|13:19||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|13:20||monteslu has joined IRC (firstname.lastname@example.org)|
|13:25||khildin has left IRC (email@example.com, Quit: I'm gone, bye bye)|
|13:41||andygraybeal_ has joined IRC (firstname.lastname@example.org)|
|13:52||gentgeen__ has left IRC (email@example.com, Read error: Connection reset by peer)|
|13:57||gentgeen__ has joined IRC (firstname.lastname@example.org)|
|14:08||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|14:18||artista_frustrad has joined IRC (email@example.com)|
|14:20||alexqwesa_ has left IRC (firstname.lastname@example.org, Quit: Хана X'ам !!!)|
|14:27||artista_frustrad has left IRC (email@example.com, Ping timeout: 246 seconds)|
|14:49||artista_frustrad has joined IRC (firstname.lastname@example.org)|
|15:55||dptech has joined IRC (email@example.com)|
|15:57||dptech has joined IRC (firstname.lastname@example.org)|
|15:59||dptech has left IRC (email@example.com, Client Quit)|
|16:16||srdjo_ has left IRC (firstname.lastname@example.org, Ping timeout: 244 seconds)|
|16:20||srdjo has joined IRC (email@example.com)|
|16:28||srdjo has left IRC (firstname.lastname@example.org, Quit: Leaving)|
|16:31||loather has joined IRC (email@example.com)|
|16:49||komunista has left IRC (firstname.lastname@example.org, Quit: Leaving.)|
|16:56||komunista has joined IRC (email@example.com)|
|17:13||alexqwesa has joined IRC (firstname.lastname@example.org)|
|17:17||dptech has joined IRC (email@example.com)|
|17:45||adrianorg__ has left IRC (firstname.lastname@example.org, Ping timeout: 244 seconds)|
|17:47||Parker955_Away is now known as Parker955|
|17:52||vagrantc has joined IRC (email@example.com)|
|18:00||khildin has joined IRC (firstname.lastname@example.org)|
|18:15|||dptech| has joined IRC (|email@example.com)|
|18:18||dptech has left IRC (firstname.lastname@example.org, Ping timeout: 272 seconds)|
|18:26||loather has left IRC (email@example.com, Quit: This computer has gone to sleep)|
|18:39||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
Hey hey hey!
|18:46||* vagrantc waves to alkisg|
|18:47||* alkisg waves back, lights a cigarette and starts working on epoptes... :)|
|18:56||komunista has left IRC (firstname.lastname@example.org, Read error: Operation timed out)|
|19:11||bobby_C has joined IRC (bobby_Cemail@example.com)|
|19:15||komunista has joined IRC (firstname.lastname@example.org)|
alkisg: Which one of the two is more dangerous to your health? :P
elias_a: haha, both are physically harmful but fun nevertheless :)
alkisg: Take care - fun job can also be done too much! :P
alkisg: Not that I would not admire your dedicated attitude :)
No worries, programming is just a hobby for me, I wouldn't want it as my main job, it'd end up being boring...
alkisg, it's quite a challenge to do 40 hours per week.
At times I've been programming even 80 hours per week... but I wouldn't want to miss the feeling of actually using in my classrooms the programs I develop
It is actually quite neat if programming something for self and actually gets it working.
|19:33||risca has joined IRC (email@example.com)|
|19:49||TatankaT_ has left IRC (TatankaT_firstname.lastname@example.org, Quit: leaving)|
alkisg: vagrantc: I was thinking of making a generic detect_arch function in ltsp-common-functions
we used to have something like that somewhere
knipwim: sounds fine! In a related subject, if we changed our packaging so that /Distro dirs were copied to /common instead, maybe we wouldn't need to detect the vendor so much, right?
or we could actually make use of the vendor-functions hooks.
although calling lsb_release is actually kind of slow, at least on debian, so i wouldn't want to use it too often.
might be worth caching the architecture somewhere at build time.
|19:59||TatankaT has joined IRC (TatankaTemail@example.com)|
seems unlikely the architecture would change.
(for a given chroot)
Is there a point to include all the /Distro dirs of ltsp-build-client? E.g. would it ever be possible for me to build a Fedora chroot while on Ubuntu?
in fact, ltsp-client-core could ship the architecture information in the package itself, since it's an architecture-specific package.
alkisg: it isn't currently, but it might be possible.
for ltsp-build-client, i don't see a huge disadvantage in shipping them all.
|20:00||Parker955 has left IRC (Parker955firstname.lastname@example.org, Ping timeout: 245 seconds)|
vagrantc: I think that it should be handled by the chroot though, not by the the server-side plugins, as (I think) those assume that the host is $DISTRO too
I'm not expressing myself well... let me try to rephrase..
Fedora/000-verify-tftpdir: cat /etc/xinetd.d/tftp ... etc
Many distro-specific ltsp-build-client plugins assume that the host is the same distro as the chroot
|20:06||Parker955 has joined IRC (Parker955email@example.com)|
alkisg: certainly the client init-ltsp.d content could be packaged this way
I think that could also be the case for ltsp-build-client, ltsp-chroot etc
if the ltsp-client package shipped a file that defines some things such as DISTRO and ARCH and so on ... that might be the simplest solution to a lot of this.
then it could be a file that's simply sourced
So e.g. ltsp-chroot would source ltsp-chroot-functions, and that file would be different per distro, but packaging would make it have the same name always
That way we wouldn't even need $DISTRO variables (but we would need $ARCH)
yes, like the example i made for ltsp-info earlier
there was an ltsp-vendor-functions, so sourced at the bottom of ltsp-common-functions ... wherein distros could ship their own functions and override the common ones.
and if distros just started making sure to ship the vendor-functions ...
vagrantc: is anyone using those?
like, is there distro that's currently using that option
|20:12||* vagrantc hasn't needed to diverge from the upstream functions|
but things like boolean_is_true ... really distro's shouldn't diverge that
knipwim: don't know ... thought fedora was.
the whole reason for the detect_arch was the line in ltsp-update-image: ARCH=$(dpkg --print-architecture)
so i think it would be better to have ltsp-common-functions with an ltsp-vendor-functions where the distro-specific detect_arch function lives.
where would they be located? server/scripts/$distro ?
Right, and override the default detect_arch() in ltsp-common-functions that uses the generic uname -m
well, the generic "uname -m" approach isn't really generic.
as in different distros map the output differently ... so there isn't even a generic, other than a proof-of-concept.
Then the generic one could die("your distro needs to impement this function")
that sounds better.
But there are cases where a generic implementation exists, and only a few distros need to override it
|20:18||* vagrantc looks at server/plugins/ltsp-build-client/*/001-set-arch|
there's a common plugin that everone overrides, for example :)
So: ltsp-tool would source ltsp-tool-functions, and ltsp-tool-functions at the end would source ltsp-vendor-function, and that file wouldn't exist upstream,
and packagers would rename the "ltsp-ubuntu-functions" or "ltsp-gentoo-functions" to "ltsp-vendor-functions" so that we wouldn't care about the distro at all
maybe ltsp-tool-vendor-functions ?
Or Vendor/ltsp-tool-functions, in the upstream tree
that way it's easier to share script between client and server packages
Could the info about ARCH (and some other things like versions needed by ltsp-info) go in /etc/ltsp/info (or system or some other name)?
Which would be a conffile generated by the packagers?
|20:26||khildin has left IRC (firstname.lastname@example.org, Quit: I'm gone, bye bye)|
|20:27||* alkisg goes back to removing zenity from epoptes, to get it ready for tomorrow :)|
|20:27||loather has joined IRC (email@example.com)|
i've noted to package ltsp-client with all init-ltsp.d in common
Ah, knipwim btw we have a grep init=/sbin/init-ltsp.d cmdline in some places in the code, which doesn't match the gentoo real_init command line,b
but |ltsp does match it... maybe we can simplify it to just grepping for ltsp? Or that's too generic?
ltsp-core: # Gracefully exit if an LTSP boot was not requested
grep -Eqsw "init=/sbin/init-ltsp|ltsp" /proc/cmdline || exit 0
Or maybe instead of passing "ltsp", we can pass "init-ltsp", and always just grep for that
|20:36||komunista has left IRC (firstname.lastname@example.org, Ping timeout: 255 seconds)|
|20:39||map7 has left IRC (email@example.com, Ping timeout: 248 seconds)|
|20:40||tbruff13 has joined IRC (tbruff13!add98621@gateway/web/freenode/ip.220.127.116.11)|
can anyone tell me how to start an ltsp server once I have it built in Kubuntu
|20:46||tbruff13 has left IRC (tbruff13!add98621@gateway/web/freenode/ip.18.104.22.168, Quit: Page closed)|
apparently not fast enough...
|20:49||tbruff13 has joined IRC (tbruff13!add98621@gateway/web/freenode/ip.22.214.171.124)|
can someone tell me out to start LTSP in kubuntu
tbruff13: what do you mean by start?
there's no specific LTSP service ... it's a collection of other services (tftp, DHCP, NFS/NBD, ssh, etc.)
how do i make the server run
I built and it is sitting in the /opt folder
but how do i enable it
it should automatically get enabled on ubuntu, as far as i know.
have you tried booting a thin client?
vagrantc: how can i check to see if it is running
tbruff13: boot a thin client...
and do i need to restart my laptop after building ltsp to make it run
"make it run" is not a helpful question ...
you installed ltsp-server on your laptop, ran ltsp-build-client ... ?
tbruff13: what happens when you try to boot a thin client?
i ran those
nothing happened Dhcp did not find it
do i need to reboot to make the server run
ok, so you need to make sure your DHCP server is running ...
pgrep -l -f dhcpd
what version of ubuntu?
oh, fun ...
Yes and I am doing these for a year long project so that a school full of computers can run LTSP in April
12.04 isn't really released yet ...
vagrantc: it is a month away I have been assured by Canonical that for my purposes there should be no bugs
tbruff13: sounds like your dhcp server isn't running, and do you have two network cards on your laptop?
tbruff13: stgraber is the ubuntu developer working on LTSP, so they'd be in a better position to help you.
this is the output of that command 30779 sudo pgrep -l -f dhcpd
tbruff13: you might want to search for step-by-step documentation on the ubuntu wiki, i don't think dhcp configuration has changed much.
tbruff13: what are you getting with "initctl list | grep isc"?
vagrantc: I followed a guide to set up LTSP
isc-dhcp-server stop/waiting isc-dhcp-server6 stop/waiting
stgraber: thank you for your help
ok, so no dhcpd running
stgraber: should i check to see if its installed?
tbruff13: what do you have in /var/log/upstart/isc-dhcp-server.log? (use paste.ubuntu.com if it's more than a few lines long)
no, you clearly have isc-dhcp-server installed, just not running. Likely because of broken configuration. /var/log/upstart/isc-dhcp-server.log should contained the reason why it didn't start
btw, who at Canonical told you it was safe to use LTSP in production at this point? I'd like to talk to that person :)
because I never said it was and I'm still planning on landing a few more network related changes and a new LTSP before the release...
stgraber: he told me the beta was safe enough to use
stgraber: it did not start
stgraber: i will be right back i am going to rebooty
|21:09||monteslu has left IRC (firstname.lastname@example.org, Ping timeout: 255 seconds)|
|21:11|||dptech| has left IRC (|email@example.com, Quit: When two people dream the same dream, it ceases to be an illusion. KVIrc 3.4.2 Shiny http://www.kvirc.net)|
tbruff13: did you put the correct subnet to your dhcpd.conf?
|21:13||tbruff13 has left IRC (tbruff13!add98621@gateway/web/freenode/ip.126.96.36.199, Ping timeout: 245 seconds)|
my guess is that he either didn't write the changes to /etc/ltsp/dhcpd.conf or that something is wrong in the config or that I messed up the upstart code for isc-dhcp
all of which would be easily figured out with the content of /var/log/upstart/isc-dhcp-server.log :)
I "think" I tried the new isc-dhcp + upstart jobs with LTSP when I uploaded it, but not completely sure...
|21:21||monteslu has joined IRC (firstname.lastname@example.org)|
|21:32||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|21:33||vagrantc has left IRC (email@example.com, Quit: leaving)|
|21:45||mikkel has left IRC (firstname.lastname@example.org, Quit: Leaving)|
|22:06||bobby_C has left IRC (bobby_Cemail@example.com, Quit: Goin' down hard)|
|22:10||adrianorg__ has joined IRC (firstname.lastname@example.org)|
|22:51||vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-246-Oregon.hfc.comcastbusiness.net)|
|23:21||andygraybeal_ has left IRC (email@example.com, Quit: Ex-Chat)|
|23:21||andygraybeal_ has joined IRC (firstname.lastname@example.org)|
|23:27||Parker955 has left IRC (Parker955email@example.com, Ping timeout: 245 seconds)|