IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 3 June 2012 (all times are UTC)
| 00:08 | F-GT has joined IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net) | |
| 00:21 | uskerine has left IRC (uskerine!~uske@80.30.244.131, ) | |
| 01:36 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 01:40 | Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Ping timeout: 248 seconds) | |
| 01:53 | Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas) | |
| 02:43 | andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net) | |
| 02:47 | Parker955_Away is now known as Parker955 | |
| 02:52 | Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas) | |
| 03:04 | andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds) | |
| 03:56 | sha has left IRC (sha!~sha@d151092.adsl.hansenet.de, Read error: Connection reset by peer) | |
| 04:00 | sha has joined IRC (sha!~sha@g231161112.adsl.alicedsl.de) | |
| 04:00 | andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net) | |
| 04:10 | adrianorg_ has left IRC (adrianorg_!~adrianorg@189.58.224.221.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds) | |
| 04:28 | andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds) | |
| 05:21 | Parker955 is now known as Parker955_Away | |
| 05:43 | Parker955_Away is now known as Parker955 | |
| 05:50 | Parker955 is now known as Parker955_Away | |
| 05:57 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 06:01 | komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk) | |
| 06:54 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 07:12 | <Hyperbyte> Okay. I officially hate, and will never ever use again, the dreaded, cursed, haunted thing that's called "NetworkManager"
| |
| 07:14 | <alkisg> Haha
| |
| 07:14 | What did it do to you again?
| |
| 07:14 | <elias_a> Hyperbyte: What is the problem this time?
| |
| 07:21 | <Hyperbyte> In the middle of the night
| |
| 07:21 | Out of nowhere
| |
| 07:21 | It decided to give eth2 (an unused nic) the IP address of eth0
| |
| 07:21 | Thus routing all eth0 traffic through eth2
| |
| 07:22 | Small detail - this is on the network server at the radio station, where eth0 is the NIC interface connecting to all servers...
| |
| 07:22 | So the servers could still access eachother, but clients couldn't access server... and servers couldn't access internet
| |
| 07:22 | <alkisg> Did someone click on that connection from the nm-applet? You should put the mac address in that connection to restrict it to eth0...
| |
| 07:23 | <Hyperbyte> alkisg, this is Fedora.
| |
| 07:23 | <alkisg> No nm-applet there?
| |
| 07:23 | <Hyperbyte> This is our network server we're talking about.
| |
| 07:23 | All critical equipment is locked down in our broadcasting backbone room...
| |
| 07:23 | The network server doesn't even have a mouse and keyboard attached.
| |
| 07:24 | Let alone a GUI.
| |
| 07:24 | <alkisg> So no nx or vnc supported?
| |
| 07:24 | <Hyperbyte> There is no GUI.
| |
| 07:24 | <alkisg> And how did you configure the connection with nm? From /etc/NetworkManager/system-connections, manually writing a file there?
| |
| 07:25 | <Hyperbyte> Jun 2 21:16:39 buster avahi-daemon[734]: Joining mDNS multicast group on interface eth2.IPv4 with address 192.168.20.1.
| |
| 07:25 | That's where it went wrong.
| |
| 07:26 | <alkisg> That's avahi, not network-manager
| |
| 07:26 | <Hyperbyte> Wait you're right.
| |
| 07:26 | But why is avahi meddling in this?
| |
| 07:26 | <alkisg> Is your network connection managed by network-manager?
| |
| 07:27 | <Hyperbyte> Wait, this is interesting
| |
| 07:27 | Moment..
| |
| 07:28 | http://razor.middelkoop.cc/~dj/networkmanager.txt
| |
| 07:28 | <alkisg> Hyperbyte: paste the output of nm-tool
| |
| 07:29 | <Hyperbyte> Looks like the device behind eth2 went down for a bit (which happens, due to the nature of the device)...
| |
| 07:29 | And it went down with 192.168.22.1, and decided to come back with 192.168.20.1
| |
| 07:29 | <alkisg> (10:22:52 πμ) alkisg: You should put the mac address in that connection to restrict it to eth0...
| |
| 07:29 | <Hyperbyte> http://fpaste.org/ijtA/
| |
| 07:30 | <alkisg> I.e. it's a misconfiguration of your system connections probably
| |
| 07:30 | <Hyperbyte> The mac address is configured in the standard Fedora configuration files... network-manager should've adopted it.
| |
| 07:30 | <alkisg> Hyperbyte: when you create a connection, you specify for which NICs it should be available
| |
| 07:31 | I don't know what fedora puts in its configuration files, but NM's system connections can work with multiple NICs
| |
| 07:32 | <Hyperbyte> alkisg, it might have to do with Fedora's implementation of NetworkManager.
| |
| 07:32 | Fedora has always had custom network configuration scripts, like /etc/network/interfaces on Ubuntu
| |
| 07:32 | <alkisg> Hyperbyte: here's my /etc/NetworkManager/system-connections/eth0,10.160.31.10: http://paste.ubuntu.com/1020877/
| |
| 07:32 | <Hyperbyte> When Fedora moved to NetworkManager, it decided to keep the custom configuration scripts, and create a module which on-the-fly parses the scripts to NetworkManager
| |
| 07:33 | <alkisg> Since I don't have a MAC entry there, if I had an eth2, and it was connected, it would use that
| |
| 07:33 | If I wanted to restrict it to eth0, I should have put its mac section in the nm configuration
| |
| 07:33 | <Hyperbyte> Right - but Fedora doesn't have that config. So I have no idea what is actually loaded in NetworkManager.
| |
| 07:34 | All I know right now is that I'm gonna get rid of avahi, and then get rid of NetworkManager
| |
| 07:34 | <alkisg> OK, sounds like a misconfiguration to me, and you should search for how to specify a MAC for each of your connections
| |
| 07:34 | <Hyperbyte> alkisg, I am specifying that
| |
| 07:35 | <alkisg> Hyperbyte: obviously not for NM
| |
| 07:35 | <Hyperbyte> http://fpaste.org/8iNB/
| |
| 07:35 | That's my /etc/sysconfig/network-scripts/ifcfg-eth2
| |
| 07:35 | <alkisg> Hyperbyte: it's possible that it's a fedora bug, but the restriction obviously doesn't reach nm
| |
| 07:35 | Or it's possible that you're missing some directive in that file
| |
| 07:35 | <Hyperbyte> Maybe.
| |
| 07:36 | Hrm
| |
| 07:36 | There's no mac address configured for eth0
| |
| 07:36 | There is one for eth2, but not eth0
| |
| 07:36 | Maybe that's why it picks eth0
| |
| 07:36 | It says so in the log actually...
| |
| 07:36 | It says 'eth2 link up' and then Auto-activating connection 'System eth0'.
| |
| 07:38 | That's -nuts-
| |
| 07:38 | "Hrm, eth2 has just come up. You know what, rather than take the config which is specific for eth2, with the exact mac address of the device that has just come up, I'll take the config for eth0"
| |
| 07:39 | Somehow this doesn't change my strong dislike of NetworkManager.
| |
| 07:42 | Whatever.
| |
| 07:42 | <alkisg> I'd blame the fedora integration, since in Ubuntu there's a mac section in the UI exactly for that
| |
| 07:42 | <Hyperbyte> alkisg, no UI... made the config by hand, forgot mac for eth0
| |
| 07:42 | Still I don't feel it should make everything eth0 just for that... especially since it doesn't happen on boot, but if eth2 goes down and then back up, it suddenly gives it eth0 config
| |
| 07:42 | <alkisg> Ah, ok, then a sysadmin error :P
| |
| 07:42 | <Hyperbyte> But I don't feel like discussing it further now - problems solved, yay!
| |
| 07:43 | So gooooooooood morning alkisg and elias_a!
| |
| 07:43 | <alkisg> Gooooood morning Hyperbyte :)
| |
| 07:43 | <Hyperbyte> Why are you guys up so early on a sunday? :P
| |
| 07:43 | <alkisg> Early? it's 10:43, I usually get up 4 hours before that... :D
| |
| 07:44 | <Hyperbyte> What!
| |
| 07:44 | How many hours do you generally sleep at night, on average?
| |
| 07:44 | <alkisg> 5-6
| |
| 07:44 | <Hyperbyte> ...
| |
| 07:44 | Wow.
| |
| 07:44 | <alkisg> Maybe 5
| |
| 07:44 | <Hyperbyte> You lucky bastard... you live about 2-3 hours long than me every day.
| |
| 07:44 | *longer
| |
| 07:45 | <alkisg> Haha and 4 hours longer than my wife, but she's going to live 20 years longer than me in return :P
| |
| 07:45 | Age also affects how much sleep each person needs, don't worry your days will expand as you grow older (yet mysteriously seem smaller)
| |
| 07:46 | <Hyperbyte> Great peptalk.
| |
| 07:46 | <alkisg> Anyway /me dives into sch-scripts again.. :(
| |
| 07:47 | <Hyperbyte> Hey no sad faces!
| |
| 07:47 | <knipwim> alkisg: while you're still here
| |
| 07:47 | https://bugs.launchpad.net/ltsp/+bug/697387
| |
| 07:47 | <alkisg> Hey knipwim
| |
| 07:47 | <knipwim> o yes, good morning guys :)
| |
| 07:48 | <Hyperbyte> Hey Wim!
| |
| 07:48 | <alkisg> knipwim: In the past I had tried remote logging successfully, but when I commented on that but I couldn't configure syslog to log in the ltsp server, dunno why...
| |
| 07:49 | s/but/bug/
| |
| 07:50 | <knipwim> at least the SYSLOG var should go methinks
| |
| 07:51 | <alkisg> Sure, the points in the bug report are valid even if I was too stupid to setup remote logging :)
| |
| 07:51 | if [ "$SYSLOG" != "localhost" ]; ...
| |
| 07:52 | Err host
| |
| 07:53 | Also the "touch" part isn't necessary now that we no longer support bind_mounts
| |
| 07:54 | And I think someone has mentioned or filed a bug about TCP vs UDP logging
| |
| 07:55 | <Hyperbyte> Awwe... don't worry about a few bugs guys, LTSP is still the coolest piece of software since... well... software!
| |
| 07:55 | <alkisg> Hehe
| |
| 07:55 | <Hyperbyte> ;-)00
| |
| 07:56 | <alkisg> knipwim: and I also agree with Xavier in the bug report, since remote logging wasn't working so far anyway, and the server needs to be specially prepared to accept the logs, we should leave it to disabled by default
| |
| 07:56 | So, we should enable it only if SYSLOG_HOST is defined in lts.conf with e.g. SYSLOG_HOST=server
| |
| 07:56 | if [ -n "$SYSLOG_HOST" ]...
| |
| 07:58 | <knipwim> hmm, wouldn't that cause a lot of breakage
| |
| 07:58 | for all systems that do have remote logging, but not explicitely defined
| |
| 07:58 | <alkisg> All non ubuntu systems? See comment #3
| |
| 07:59 | I don't know if in other systems /etc/rsyslog.d/ltsp.conf actually overrides the defaults
| |
| 07:59 | In Ubuntu, it doesn't (or didn't last time I checked)
| |
| 08:01 | <knipwim> Gentoo uses sysklogd
| |
| 08:02 | <alkisg> And for all the other users of distros where ltsp.conf is actually in effect, it causes unnecessary network delays _unless_ they have setup remote logging in their server
| |
| 08:03 | I think saving that bandwidth (and possibly security issues because of the logs showing up on the network) is more important than keeping compatibility in this case
| |
| 08:04 | <knipwim> also the possibility of installing ltsp client on an existing install
| |
| 08:06 | <alkisg> We can just note in lts.conf manpage that "from ltsp 5.4.0 and on, SYSLOG_HOST is unset by default, and you need to set it to e.g. "server" in order to get remote logging to work. Of course you need to configure your server as well. And btw remote logging didn't work for ubuntu and possibly debian users in the past" :)
| |
| 08:08 | uskerine has joined IRC (uskerine!~uske@80.30.244.131) | |
| 08:38 | <knipwim> and pushed
| |
| 08:39 | will do the lts.conf.xml as well, making use of my new xxe :)
| |
| 08:39 | <alkisg> Hehe :)
| |
| 08:39 | Nic!
| |
| 08:39 | e
| |
| 08:40 | <uskerine> i have setup two LTSP servers
| |
| 08:40 | how can i make sure there is one active and the other one backup?
| |
| 08:40 | should is shutdown tftp dnsmasq and nbd?
| |
| 08:41 | <alkisg> Just dnsmasq
| |
| 08:41 | Hyperbyte: can you tell me again about the new dconf defaults/mandatory settings?
| |
| 08:42 | <uskerine> this is an easy one (and a bit offtopic), how can i prevent dnsmasq starting at boot time in ubuntu ?
| |
| 08:42 | <alkisg> /etc/default/dnsmasq
| |
| 08:43 | <uskerine> and, as i commented out #port 0, is dnsmasq not required for regular name resolution?
| |
| 08:43 | <alkisg> port 0 disables dns
| |
| 08:43 | If you uncomment it, you enable dns
| |
| 08:43 | *if you comment it, you enable dns
| |
| 08:44 | Normally ltsp doesn't involve dns resolution, it's up to you if you want that or not
| |
| 08:44 | <uskerine> i had the 127.0.0.1 name resolution issue, vagrantc suggested to comment it out and everything worked fine
| |
| 08:47 | is ltsp-cluster recommended for two-server LTSP installation?
| |
| 08:47 | <alkisg> So you solved your dns problem by "installing" a dns server. You could have solved it "normally" instead, i.e. from resolvconf.
| |
| 08:47 | <uskerine> will it make my life more simple or more complex?
| |
| 08:48 | * alkisg can't comment on ltsp-cluster as he never even seen it. But I believe it's for more complex installations. | |
| 08:48 | <uskerine> ok
| |
| 08:48 | thks
| |
| 08:50 | well i stop dnsmasq and resolution still works
| |
| 08:50 | so i will try that way (disabling dnsmasq in the backup server, it will be enabled only when the server is actually used as backup)
| |
| 08:57 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection) | |
| 08:59 | <alkisg> Heeey why are we bothering writing man pages? help2man generates a man page by just running ltsp-tool --help internally!!!
| |
| 09:08 | Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas) | |
| 09:11 | <alkisg> Filed https://bugs.launchpad.net/ltsp/+bug/1008053 about it
| |
| 09:26 | rkwesk_ has joined IRC (rkwesk_!~rkwesk@adsluser1289.att.sch.gr) | |
| 09:27 | <rkwesk_> hello anyone
| |
| 09:28 | <Hyperbyte> o, hi!
| |
| 09:29 | <rkwesk_> hi. i have a situation with dns-nameservers in /etc/interfaces
| |
| 09:29 | <Hyperbyte> !ask
| |
| 09:29 | <ltsp`> Hyperbyte: ask: Don't ask to ask a question, simply ask it, and if someone knows the answer, they'll respond. Please hang around for at least 15 minutes after asking a question, as not everybody constantly monitors the channel.
| |
| 09:29 | <rkwesk_> yes, ok
| |
| 09:30 | <alkisg> And mention your distro/version as well
| |
| 09:31 | <rkwesk_> i use ltsp with ubuntu 12.04 but with ts.sch.gr's version. I am in Greece
| |
| 09:32 | <Hyperbyte> Go on... :)
| |
| 09:32 | <rkwesk_> i set a static ip for server in /etc/network/interfaces including the gateway and dns-nameservers lines
| |
| 09:32 | <alkisg> rkwesk_: are you trying out the ltsp-pnp method?
| |
| 09:33 | <rkwesk_> sometimes this works but more often than not the resovconfig doesn't set the dns
| |
| 09:34 | alkis, i now am using the version you put at the end of May
| |
| 09:34 | <alkisg> rkwesk_: it's recommented to use network-manager to manage your interfaces, ip, dns etc
| |
| 09:34 | So please revert /etc/network/interfaces back to the way it was, and create a system connection from network manager
| |
| 09:34 | Ubuntu introduced a "local resolver" hack and they haven't polished out some bugs yet
| |
| 09:35 | <rkwesk_> a bad hack that does work 4 me is to rewrite the head file in /etc/resolvconfig
| |
| 09:35 | <alkisg> But it works if you're using network manager
| |
| 09:35 | /etc/resolvconf is autogenerated, you shouldn't touch it
| |
| 09:35 | <rkwesk_> ok i have had bad luck in past but will try nm again now
| |
| 09:35 | <alkisg> For more info see here: http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/
| |
| 09:36 | But basically you just need to revert to network manager
| |
| 09:36 | <rkwesk_> thank you
| |
| 09:36 | <alkisg> You can do it with resolvconf too, it's just not recommented, it's best if all greek schools use the same settings for easier troubleshooting
| |
| 09:36 | You're welcome, ping me if you hit any problems with it
| |
| 09:37 | Remember to check [x] Allow all users to use this connection and [x] Connect automatically from network manager
| |
| 09:38 | <rkwesk_> another point, if i may is it would be good if there was an iso for 12.04 using fallback by default without having so much other software baggage
| |
| 09:38 | <alkisg> rkwesk_: sch-scripts will install and use gnome-fallback-session by default
| |
| 09:39 | So if you wait until the end of June, you'll get a much easier installation and a full guide in the ts.sch.gr wiki
| |
| 09:39 | <rkwesk_> ok
| |
| 09:39 | <alkisg> You can still install ltsp-pnp now, but you'll have to do some things manually
| |
| 09:40 | <rkwesk_> it is better if we r all on same page
| |
| 09:40 | <alkisg> Right. Those few that prefer unity will still be able to select it though, by just modifying 1 line in lts.conf.
| |
| 09:41 | Btw about your original problem, from the page I linked above: I use static IP configuration, where should I put my DNS configuration?
| |
| 09:41 | The DNS configuration for a static interface should go as “dns-nameservers”, “dns-search” and “dns-domain” entries added to the interface in /etc/network/interfaces"
| |
| 09:41 | <rkwesk_> i meant in the sense that other issues like what we be visible to clients and what to hide may be affected by the software installed
| |
| 09:41 | <alkisg> (...but it's still recommented to use nm)
| |
| 09:42 | <rkwesk_> yes, ok i will try again with nm
| |
| 09:42 | <alkisg> True, the wiki and sch-scripts will propose a default installation method. But if someone wants to divert, he's allowed to do so.
| |
| 09:43 | *diverge
| |
| 09:43 | <rkwesk_> as i will put same install in several schools and leave less experienced sysadmins to it it would be better to follow default
| |
| 09:46 | <alkisg> rkwesk_: we'll be having an installation seminar in athens at june 22th, if you want you could come to the 4th lykeio of alimos and attend it
| |
| 09:46 | <rkwesk_> yes, ok i will come
| |
| 09:47 | <alkisg> About 70-80 teachers will come and some will bring their servers before the seminar to have them installed and get them at the end of the seminar
| |
| 09:47 | <rkwesk_> i will let hellug know
| |
| 09:49 | <alkisg> rkwesk_: dide-d-ath.att.sch.gr/ubuntu.pdf - but the date was changed due to the elections, we moved it to 21th and 22th.
| |
| 09:50 | It requires a (free) reservation but we can make an exception for you :)
| |
| 09:50 | <rkwesk_> thank you :))
| |
| 09:50 | <alkisg> Other teachers can contact their councelor at the mail in the pdf
| |
| 09:51 | <rkwesk_> tftp is another topic i want to mention
| |
| 09:52 | in order to put windows in the mix isn't there the remapping thing that dnsmasq doesn't do?
| |
| 09:54 | <alkisg> What remapping?
| |
| 09:54 | And what windows have to do with tftp in the first place?
| |
| 09:55 | <rkwesk_> i may have the term wrong. i found on internet that changing forward slash to backward slash is the issue
| |
| 09:55 | <alkisg> What would you use tftp from windows for?
| |
| 09:55 | <rkwesk_> if some want to serve up windows as well as linux
| |
| 09:56 | <alkisg> The image isn't served with TFTP, you probably have a misconception somewhere
| |
| 09:56 | That's only for the kernel, and this is loaded before Windows starts, from the BIOS
| |
| 09:56 | <rkwesk_> i never use windows but when i go 2 a school some want 2 use windows also
| |
| 09:57 | <alkisg> If you wanted to serve windows, you'd still wouldn't be using Windows when you downloaded their "kernel"
| |
| 09:57 | It's the PXE stage, before Windows runs.
| |
| 09:57 | <rkwesk_> ok. i'll go back and try 2 get my facts straight
| |
| 09:58 | <alkisg> We're preparing 2 solutions for windows users, one based on windows 2008 server in a VM + ltsp + xfreerdp, for thin clients,
| |
| 09:58 | and another with a non-server windows VM + ltsp fat clients + virtualbox
| |
| 09:58 | But not for this September, maybe for the next one
| |
| 09:59 | <rkwesk_> the discussion mentioned that tftpd-hpa will do this remapping that dnsmasq wouldn't (I think)
| |
| 10:00 | <alkisg> rkwesk_: netbooted windows clients don't use tftp to access their disk
| |
| 10:01 | <rkwesk_> ok i will try 2 dig deeper 2 see what was actually being discussed
| |
| 10:02 | i prefer dnsmasq
| |
| 10:20 | rkwesk_ has left IRC (rkwesk_!~rkwesk@adsluser1289.att.sch.gr, Quit: Leaving) | |
| 10:28 | andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net) | |
| 10:33 | <knipwim> alkisg: i like the help2man idea
| |
| 10:33 | <alkisg> knipwim: I did a bit of testing and it seems pretty nice, we don't even need to add --version to our scripts, it has a command line switch that we can use while building the package
| |
| 10:34 | <knipwim> can it be included in autogen.sh? which reads the release.conf?
| |
| 10:34 | at least, that's what i thought was the most practical
| |
| 10:34 | <alkisg> Sounds like a good idea
| |
| 10:34 | <knipwim> but don't know a lot about automake
| |
| 10:35 | * alkisg neither... I leave the packaging stuff to vagrantc :) | |
| 10:35 | <alkisg> It even supports a --help-option=STRING option, and we can pass --extra-help there for ltsp-build-client
| |
| 10:36 | <knipwim> i saw
| |
| 10:36 | <alkisg> So other than deleting the existing man pages and modifying autogen.sh, we shouldn't need any more upstream changes
| |
| 10:37 | <knipwim> perhaps adding some SEE ALSO sections to the --help outputs
| |
| 10:37 | or some other beautifications
| |
| 10:37 | <alkisg> Copyright etc, yeah
| |
| 10:49 | Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71) | |
| 10:53 | vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 246 seconds) | |
| 11:04 | staffencasa has joined IRC (staffencasa!~staffenca@128.193.8.220) | |
| 11:06 | vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi) | |
| 11:13 | richard has joined IRC (richard!~rkwesk@adsluser1289.att.sch.gr) | |
| 11:14 | richard is now known as Guest96570 | |
| 11:15 | <Guest96570> hello again i am back to continue tftp discussion re remapping
| |
| 11:15 | <alkisg> Hi Richard, what link are you reading?
| |
| 11:16 | <Guest96570> sorry about id
| |
| 11:16 | Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Ping timeout: 260 seconds) | |
| 11:16 | <alkisg> Type "/nick rkwesk"
| |
| 11:16 | <Guest96570> the link was http://www.funtoo.org/wiki/PXE_network_boot_server
| |
| 11:16 | Guest96570 is now known as rkwesk | |
| 11:17 | <rkwesk> the line was "DNSMasq actually provides a tftp server if you want to use it, however I recommend the use of tftp-hpa as it allows remapping in the event you ever intend to boot a Windows environment over your network."
| |
| 11:18 | it may simply not interest our schools. i don't know
| |
| 11:18 | it was indeed about changing slashes
| |
| 11:19 | <alkisg> rkwesk: do you want to install windows over the network or run windows over the network?
| |
| 11:20 | <rkwesk> i just wanted 2 explore what a school might want
| |
| 11:20 | if it just involves installing then probably few schools would want it
| |
| 11:21 | <alkisg> Netbooting windows is much, much harder than netbooting linux
| |
| 11:22 | You'd need to specially prepare an image with aoe or iscsi drivers and it'll only work for a single client
| |
| 11:22 | <rkwesk> it doesn't surprise me :))
| |
| 11:22 | <alkisg> And tftp is not involved there
| |
| 11:23 | What you could do is create an installation server, there are many tutorials about that, and even packages that you could use
| |
| 11:23 | <rkwesk> so in short remapping is not an issue 4 most
| |
| 11:23 | <alkisg> But schools wouldn't really care about that, they'd care more about a cloning solution or a VM/xfreerdp+linux based solution to run windows on top of linux
| |
| 11:23 | Because then a single image can be used in all clients
| |
| 11:24 | <rkwesk> yes, ok.
| |
| 11:25 | andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds) | |
| 11:25 | <alkisg> Yes remapping shouldn't be an issue for any greek school. And if it was, it could just install tftpd-hpa and keep dnsmasq for the proxydhcp mode.
| |
| 11:25 | <rkwesk> thank you 4 sorting this point 4 me.
| |
| 11:25 | <alkisg> np
| |
| 11:27 | staffencasa has left IRC (staffencasa!~staffenca@128.193.8.220, Ping timeout: 244 seconds) | |
| 11:28 | Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas) | |
| 11:31 | rkwesk has left IRC (rkwesk!~rkwesk@adsluser1289.att.sch.gr, Quit: Leaving) | |
| 11:37 | Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!") | |
| 11:45 | <alkisg> knipwim: So far I got help2man to automatically extract those man page sections from the program output:
| |
| 11:45 | NAME, SYNOPSIS, DESCRIPTION, OPTIONS, ENVIRONMENT, FILES, EXAMPLES, REPORTING BUGS, COPYRIGHT.
| |
| 11:45 | Didn't manage yet to make it extract: other, AUTHOR, SEE ALSO.
| |
| 11:47 | Ah ok with AUTHOR
| |
| 11:54 | <knipwim> cool
| |
| 11:56 | you're extracting those from ltsp-tool, or with the help of an include file?
| |
| 11:56 | <alkisg> From ltsp-tool
| |
| 11:59 | <knipwim> well, SEE ALSO doesn't have to be included i think
| |
| 12:00 | <alkisg> I'll file a bug in help2man though if I can't get it to work
| |
| 12:01 | The SEE ALSO section will still be included as normal text, it just won't be a special section
| |
| 12:01 | (bold letters etc)
| |
| 12:02 | At some point I'd like us to have translatable "usage" texts
| |
| 12:02 | We do already for ltsp-build-client, so it shouldn't be much of a change
| |
| 12:02 | And help2man will then automatically create localized man pages
| |
| 12:04 | <knipwim> i almost can't believe this hasn't been done sooner
| |
| 12:05 | <alkisg> Shows how much most devs care about documentation :P
| |
| 12:08 | Ah it appears that help2man can only produce the GNU-related "info" output in the "SEE ALSO" section. So we can use --opt-include=$ltsp-tool.inc if we want, or omit SEE ALSO.
| |
| 12:25 | litlebuda has joined IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt) | |
| 12:36 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 244 seconds) | |
| 12:40 | adrianorg_ has joined IRC (adrianorg_!~adrianorg@189.58.224.221.dynamic.adsl.gvt.net.br) | |
| 13:13 | Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71) | |
| 13:29 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 13:56 | Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Ping timeout: 248 seconds) | |
| 14:09 | ricotz has joined IRC (ricotz!~rico@p5B2ACE33.dip.t-dialin.net) | |
| 14:09 | ricotz has joined IRC (ricotz!~rico@unaffiliated/ricotz) | |
| 14:14 | Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas) | |
| 14:17 | komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Ping timeout: 245 seconds) | |
| 14:33 | komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk) | |
| 14:50 | litlebuda has left IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt, Remote host closed the connection) | |
| 15:08 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com) | |
| 15:49 | vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net) | |
| 15:49 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 16:17 | <knipwim> hey vagrantc !
| |
| 16:18 | alkisg and i were entertaining the idea of removing BASE and TFTPDIRS from the commandline options of all ltsp-tools
| |
| 16:19 | and put those in common.conf
| |
| 16:20 | certainly TFTPDIRS can be moved there; these are system specific
| |
| 16:20 | <vagrantc> that would basically mean you can only have it once?
| |
| 16:20 | i.e. you couldn't experiment with another BASE dir ... but that's prretty niche
| |
| 16:20 | <knipwim> yeah, i was wondering about that option for BASE as well
| |
| 16:20 | <vagrantc> well, you could, but not on the fly ... supporting multiple BASE dirs probably doesn't work well anyways...
| |
| 16:21 | since all the various tools would need to consistantly have the option passed on the commandline ...
| |
| 16:21 | sounds reasonable...
| |
| 16:21 | <knipwim> yes, and passed onwards, for example from ltsp-update-image to ltsp-config
| |
| 16:21 | <vagrantc> (putting BASE and TFTPDIRS in common.conf)
| |
| 16:22 | <knipwim> which is not happening now
| |
| 16:22 | <vagrantc> if we made it possible to specify an alternate config dir, that would make it easier to consistantly support multiple BASE dirs ...
| |
| 16:23 | <knipwim> or just change the value in common
| |
| 16:24 | <vagrantc> sure, but supporting multiple common.conf's would require specifying another config dir
| |
| 16:24 | but i don't think it's worth the trouble, really.
| |
| 16:24 | <knipwim> or move more from $arch to $name, for instance /opt/ltsp/i386-test or /opt/ltsp/my-test-env
| |
| 16:25 | <vagrantc> right, typically that's enough to make it work well.
| |
| 16:26 | <knipwim> btw, have you seen alkisg's next briliant idea? about the help2man?
| |
| 16:37 | <vagrantc> not yet...
| |
| 16:37 | * vagrantc looks | |
| 16:39 | <vagrantc> i've thought about that in the past ... i even took a stab at it once ... we'll have to make sure out --help output is formatted in a way that help2man expects.
| |
| 16:39 | but generating the manpage are build time would allow things like distro-specific plugin options being documented
| |
| 16:39 | which is cool
| |
| 16:53 | <alkisg> (07:20:10 μμ) vagrantc: that would basically mean you can only have it once? ==> if common.conf has BASE=${BASE:-/opt/ltsp}, then one can override it with BASE=xx ltsp-update-image params
| |
| 16:54 | But then the .conf syntax is a bit weird
| |
| 16:54 | F-GT has left IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net, Ping timeout: 260 seconds) | |
| 16:58 | <uskerine> i asked yesterday and i think alkisg answered, but i can not find it, how do i disable the dnsmasq service so in an environment with two servers the backup will not enter into the game unless the service is manually started?
| |
| 16:58 | <alkisg> /etc/default/dnsmasq
| |
| 16:58 | vagrantc: does it make sense to have both 64bit and 32bit kernels in the same chroot? (about ifcpu64...)
| |
| 16:59 | <uskerine> thks
| |
| 17:00 | <vagrantc> alkisg: i have some use-cases for that, yes.
| |
| 17:01 | <alkisg> vagrantc: yesterday I though that ifcpu64 could show diffeferent menu items based on the client CPU, but it can't, it can only jump to different labels,
| |
| 17:01 | <vagrantc> alkisg: booting 64-bit machines from a 32 bit chroot, where i want the proper memory handling of a genuine 64-bit kernel, but don't want to maintain a separate userland.
| |
| 17:01 | <alkisg> so we can either use it in a "master" /var/lib/tftpboot/pxelinux.cfg/default, which chains to 2 different ltsp menus, or in a menu item, "boot kernel version xxx", where it selects between a few kernels to boot
| |
| 17:01 | And I'm thinking what of those best suits us
| |
| 17:02 | vagrantc: is booting 32bit chroots with 64bit kernels debian-specific? E.g. can I do that in Ubuntu? The kernels here don't even have different package names...
| |
| 17:05 | <vagrantc> alkisg: i don't know what ubuntu supports, i'm guessing there's no technical reason it couldn't be done, although as you point out, the filenames are identical, so it probably makes it difficult.
| |
| 17:06 | alkisg: you could probably use multi-arch to install the amd64 kernel in the i386 userland.
| |
| 17:06 | * alkisg is suprised that an 64bit kernel can work with 32bit libs though | |
| 17:06 | <vagrantc> alkisg: so theres generic:amd64, generic:i386, generic-pae:i386 ?
| |
| 17:06 | <alkisg> Right
| |
| 17:07 | And lowlatency and virtual, for both arches
| |
| 17:07 | <vagrantc> so generic:amd64 and generic-pae:i386 could co-exist ... but that's not the most useful use-case.
| |
| 17:09 | <alkisg> vagrantc: I'd even have to change my sources to install the 64bit kernel, and that might cause havoc with my system
| |
| 17:10 | OK let's view it from another perspective. Multiple chroots, one for amd64 and one for i386. How useful is to use ifcpu64 on that?
| |
| 17:10 | <vagrantc> it should still treat "i386" as the native/preferred arch, unless multiarch isn't working properly.
| |
| 17:10 | alkisg: that seems *really* useful.
| |
| 17:10 | * alkisg hasn't read about multiarch yet | |
| 17:11 | <alkisg> In the previous case we were talking about, ifcpu64 would be used after the user selects a menu
| |
| 17:12 | In this case, ifcpu64 would be the default, and it would select between 2 different ltsp/<arch>/pxelinux.cfg/default menus
| |
| 17:13 | Phantomas1 has joined IRC (Phantomas1!~Phantomas@unaffiliated/phantomas) | |
| 17:13 | Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Disconnected by services) | |
| 17:13 | Phantomas1 is now known as Phantomas | |
| 17:14 | <alkisg> For the first case again, I believe we only want ifcpu64 for the first ltsp entry, not for the "other/older kernels" submenu, right?
| |
| 17:15 | If the user wants to go in there, we should allow him to choose e.g. the 486 kernel even if he has a 64bit cpu and the 64bit kernel is available
| |
| 17:16 | And, for the second case to work, we'll need absolute tftp paths in ltsp/i386/pxelinux.cfg/default
| |
| 17:16 | <vagrantc> alkisg: that seems reasonable, though i could see allowing autodetection even in the submenus.
| |
| 17:16 | <alkisg> Let's not make it too complicated though... :-/
| |
| 17:16 | <vagrantc> alkisg: yeah, that's what i was thinking
| |
| 17:17 | alkisg: so it seems like autodetection should go something like: if amd64 and amd64 chroot, boot amd64 chroot, if amd64 and i386 chroot only, boot i386 chroot with amd64 ...
| |
| 17:17 | <alkisg> With that scheme we can still make it with only 2 files,ltsp and ltsp-old. And for the second case, a master TFTP/pxelinux.cfg/default is needed as well, and a bit of change in how we detect the lts.conf path (we'd take it from the cmdline instead of dhcp)
| |
| 17:18 | <vagrantc> if no amd64 kernel in i386, boot pae kernel, fallback to nonpae kernel in i386 chroot
| |
| 17:21 | <alkisg> Master ifcpu64 call: check for chroots named amd64 / i386. Nothing -pae related there.
| |
| 17:21 | <vagrantc> though now that we're talking about multiple chroots, it sounds like we're talking about pxemenus and not in-chroot pxelinux configuration
| |
| 17:21 | <alkisg> Secondary ifcpu64 call, only in the i386 chroot: check for pae or i386 kernel.
| |
| 17:21 | The master one will be generated by ltsp-update-kernels, the secondary ones by update-kernels.
| |
| 17:22 | <vagrantc> alkisg: you're chaining ifcpu64 calls?
| |
| 17:22 | <alkisg> Right, we need 2 of them to make both cases work
| |
| 17:22 | The first one is to select the chroot to boot
| |
| 17:22 | It's executed without a menu. It selects a chroot and loads vesamenu.c32 with the path to the chroot configuration file, /ltsp/<arch>/pxelinux.cfg/default
| |
| 17:22 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving) | |
| 17:23 | <vagrantc> alkisg: with the secondary call (the i386 chroot call) i still want to be able to boot an amd64 kernel with an i386 chroot
| |
| 17:23 | <alkisg> Right, but what name would you check for?
| |
| 17:23 | Parker955_Away is now known as Parker955 | |
| 17:23 | <vagrantc> kernel name? -amd64 :P
| |
| 17:24 | it's easy on debian, ubuntu makes it hard :P
| |
| 17:24 | (admittedly it's probably a lot simpler to have a -generic kernel on all arches)
| |
| 17:25 | <alkisg> OK, so debian would have "ifcpu64 amd64 -- 686 -- 486", and ubuntu would have "ifcpu64 generic-pae -- generic-pae -- generic" - of course only if those exist
| |
| 17:25 | ...or something, dunno what else could be done with multiarch given the ubuntu kernel names
| |
| 17:26 | <vagrantc> alkisg: that seems like the best you can do
| |
| 17:26 | <alkisg> Now, if the user wants to have different chroots like "nvidia-clients-i386" and "ati-clients-amd64", I don't see how we can help him :P
| |
| 17:26 | He'd have to specify them in dhcp
| |
| 17:27 | <vagrantc> alkisg: actually, though, on debian the -686 kernels do not necessarily support pae.
| |
| 17:27 | alkisg: -686-pae supports pae, -686 does not.
| |
| 17:27 | <alkisg> Then you'd check for both of them and put them in the "pae" placeholder
| |
| 17:27 | <vagrantc> alkisg: so it'd be more like amd64 -- 686-pae|686-bigmem -- 486|686
| |
| 17:28 | <alkisg> ...ifcpu64 supports | ?
| |
| 17:28 | The choice would be done from update-kernels, no?
| |
| 17:28 | <vagrantc> no, just trying to map the potentials to kernel names
| |
| 17:28 | <alkisg> OK, so update-kernels would only put 686-pae there if both it and plain 686 were installed
| |
| 17:29 | In other words, we need 3 lists
| |
| 17:29 | <vagrantc> alkisg: it basically depends on if you're using squeeze or wheezy ... 686-bigmem -> 686-pae and 686 -> 486
| |
| 17:29 | <alkisg> LIST_KERNELS_AMD64, LIST_KERNELS_PAE, LIST_KERNELS_I386
| |
| 17:29 | <vagrantc> there is no wheezy equivalent to plain 686
| |
| 17:30 | yup, so: LIST_KERNELS_AMD64="-amd64" LIST_KERNELS_PAE="686-pae 686-bigmem" LIST_KERNELS_I386="486 686"
| |
| 17:31 | <alkisg> For Ubuntu: LIST_KERNELS_64="lowlatency-pae lowlatency virtual-pae virtual generic-pae generic", LIST_KERNELS_PAE="lowlatency-pae lowlatency virtual-pae virtual generic-pae generic", LIST_KERNELS_I386="lowlatency virtual generic"
| |
| 17:31 | <vagrantc> if the preference is listed that way
| |
| 17:31 | i.e. first one gains preference
| |
| 17:31 | <alkisg> Right, ok we'll see if we need to list the rest of them or if they're implied
| |
| 17:32 | <vagrantc> oh, right, i'd need to add the -pae as alternates for amd64, in case there was no amd64 kernel.
| |
| 17:32 | <alkisg> And the 486/686 ones too
| |
| 17:32 | With the opposite order there
| |
| 17:32 | <vagrantc> yup, so: LIST_KERNELS_AMD64="amd64 686-pae 686-bigmem" LIST_KERNELS_PAE="686-pae 686-bigmem" LIST_KERNELS_I386="486 686"
| |
| 17:33 | <alkisg> IST_KERNELS_AMD64="amd64 686-pae 686-bigmem 686 486"
| |
| 17:33 | LIST_KERNELS_PAE="686-pae 686-bigmem 686 486"
| |
| 17:33 | <vagrantc> alkisg: shouldn't we just append each list?
| |
| 17:33 | <alkisg> The order is not the same, 686 is preferred in amd64 cpus
| |
| 17:34 | <vagrantc> since AMD64 could run anything in PAE, and PAE could run anything in I386
| |
| 17:34 | eesh.
| |
| 17:34 | <alkisg> If you appended the lists, you'd get LIST_KERNELS_AMD64="amd64 686-pae 686-bigmem 486 686" instead of LIST_KERNELS_AMD64="amd64 686-pae 686-bigmem 686 486" - last 2 swapped
| |
| 17:35 | <vagrantc> and in order to support PAE, you need to support amd64.
| |
| 17:35 | alkisg: i'm ok with that level of wrongness.
| |
| 17:35 | <alkisg> It doesn't matter much; it's just 3 lines in a configuration file
| |
| 17:36 | Whatever, both work for me, I don't even need pxemenus now with ltsp-pnp, just to prefer the non-pae kernel if it's installed, and cleanup.d already does that :P
| |
| 17:37 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com) | |
| 17:37 | komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Quit: Leaving.) | |
| 17:37 | <alkisg> I think that the problem with writing the whole path in ltsp/i386/pxelinux.cfg/ltsp can be amended with ltsp-update-kernels sed'ing through the files while copying them
| |
| 17:38 | ...as the chroot currently doesn't not need to know its name, we'd best keep it that way unless we have to
| |
| 17:38 | <vagrantc> right.
| |
| 17:40 | <alkisg> About the master TFTP/pxelinux.cfg/default, since we'd like the user to be able to edit it (e.g. to specify different chroot ordering in the menus or list them in submenus or whatever), I propose that ltsp-update-kernels puts the ifcpu64 call in TFTP/pxelinux.cfg/ltsp, and that pxelinux.cfg/default INCLUDEs that
| |
| 17:40 | So all in all we'll be writing some files under the pxelinux.cfg/ dirs, but we'll only be regenerating the ltsp and ltsp-old ones
| |
| 17:40 | <vagrantc> alkisg: ok, so AMD64="amd64 $PAE" PAE="686-pae 686-bigmem 686 $I386" I386="486 686"
| |
| 17:40 | <alkisg> OK, in the opposite order of declaration
| |
| 17:41 | <vagrantc> well, we can just append them, and if things are repeated, that shouldn't matter?
| |
| 17:41 | <alkisg> No I mean that the $PAE variable isn't yet declared if you declare AMD64 first
| |
| 17:41 | <vagrantc> by repeating 686 in PAE, i think that solves the little problem you mentioned, and all pae supporting stuff can run 686
| |
| 17:42 | alkisg: well, thta was more concceptually
| |
| 17:42 | <alkisg> Those would go in /etc/ltsp/update-kernels.conf, shipped by distros, right?
| |
| 17:42 | <vagrantc> alkisg: i think the code would be more like for variant in $AMD64 $PAE $I386 ; do ...
| |
| 17:42 | alkisg: that's what i'm thining
| |
| 17:43 | <alkisg> ifcpu64_amd_entry=$(list_kernels $AMD64 | head -n 1)
| |
| 17:43 | No need to loop
| |
| 17:44 | <vagrantc> list_kernels $AMD64 $PAE $i386 for amd64, list_kernels $PAE $I386 for pae, and list_kernels $I386 for the rest
| |
| 17:44 | komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk) | |
| 17:44 | <alkisg> Sounds better
| |
| 17:44 | <vagrantc> that way you don't have to AMD64="amd64 $PAE"
| |
| 17:44 | <alkisg> Right
| |
| 17:44 | <vagrantc> sorry i didn't explain myself better
| |
| 17:45 | * vagrantc keeps using pseudo-code ideas and failing | |
| 17:45 | <alkisg> Although in Ubuntu we'd probably have to leave AMD64="" because of the same kernel names with I386, to prevent duplicates
| |
| 17:45 | <vagrantc> :(
| |
| 17:46 | alkisg: could also ship a different update-kernels.conf in amd64 vs. i386
| |
| 17:46 | <stgraber> yeah, as of 12.10 we'll have linux-image-generic on both i386 and amd64. The i386 one being a PAE kernel, we won't have non-PAE variants anymore.
| |
| 17:46 | <vagrantc> well, that simplifies things a bit.
| |
| 17:47 | <stgraber> we have slightly different naming conventions for the ARM kernel though and as ogra wants to have proper ARM support for 12.10, we might need some magic for these
| |
| 17:47 | <alkisg> stgraber: pxelinux doesn't work in arm, does it?
| |
| 17:47 | <stgraber> (as ARM tends to work on a per-SOC basis...)
| |
| 17:47 | <alkisg> All those are pxelinux related...
| |
| 17:47 | <stgraber> alkisg: not sure for pxelinux itself but we definitely have PXE support on ARM now (in uboot)
| |
| 17:47 | <vagrantc> y'all need to fix your ltsp-build-client plugins to work better on arm :P
| |
| 17:48 | <stgraber> vagrantc: yeah, I believe I gave ogra a work item for that ;)
| |
| 17:48 | <vagrantc> it currently defaults to imx5 or something
| |
| 17:48 | <alkisg> (08:46:49 μμ) vagrantc: well, that simplifies things a bit. => nah it even makes it impossible to have a pae and an 64bit kernel, which worked in 12.04. But meh all this is way beyond my use cases :)
| |
| 17:49 | <vagrantc> alkisg: i've got weird use-cases :)
| |
| 17:49 | * alkisg will leave most of the pxemenus implementation and testing to vagrantc then, after the design process :P | |
| 17:50 | <alkisg> I need to dive in sch-scripts this month, we have a seminar for them in the 21th
| |
| 17:51 | <vagrantc> sounds reasonable.
| |
| 17:53 | <alkisg> Having full tftp paths also helps in deciding the nbd or nfs name when ipappend=3 is used, where rootpath isn't available
| |
| 17:53 | And we could make 2 attempts to retrieve lts.conf, one in the subdir and if that's missing maybe also check for a master one in TFTP/lts.conf
| |
| 17:54 | <vagrantc> alkisg: yeah, i've thought about that sometimes
| |
| 17:55 | it would be nice, actually, to have a single lts.conf, as long as it was possible to override on per-chroot basis.
| |
| 17:56 | <alkisg> We could easily add them... Although I don't want to invest in lts.conf too much, I prefer an /etc/ltsp/lts.conf.d dir with shell scripts...
| |
| 17:57 | <vagrantc> mhmm
| |
| 17:58 | Parker955 is now known as Parker955_Away | |
| 17:59 | Parker955_Away is now known as Parker955 | |
| 18:00 | <alkisg> So, get the master lts.conf, evaluate it, get the subdir lts.conf, evaluate it - it overrides the master options
| |
| 18:01 | <vagrantc> alkisg: you could implement it as an early running ltsp_config.d hook, no?
| |
| 18:03 | <alkisg> Sure
| |
| 18:04 | <vagrantc> which could overwrite the existing lts.conf, or simply set variables later.
| |
| 18:04 | <alkisg> It could save it with a different name, and we'd source both of them when needed
| |
| 18:05 | <vagrantc> you can do anything you put your mind to :)
| |
| 18:07 | speaking of which, i was going to be testing ldm
| |
| 18:10 | * alkisg thinks ltsp_config is too complex and too slow and needs a rewrite :-/ | |
| 18:11 | <alkisg> (not for now, for/if when we implement the /etc/ltsp/lts.conf.d mechanism)
| |
| 18:11 | * vagrantc would definitely prefer that for ltsp 5.5 ... | |
| 18:37 | Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!") | |
| 18:38 | <vagrantc> alkisg: ok, so LDM_DESKTOP forces use of the specified desktop? LDM_DESKTOP_DEFAULT sets the default but allows the user to override?
| |
| 18:43 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 18:54 | <vagrantc> alkisg: there's some weird issue with the new LDM ... after logging in ... the login window/logo shift to the left ...
| |
| 18:59 | <alkisg> vagrantc: about LDM_DESKTOP, yes. I did hear someone say that LDM_SESSION _doesn't_ force a session though...
| |
| 18:59 | (from the greeter)
| |
| 18:59 | vagrantc: about the login window/logo, it's something related to wwm, I noticed it a few months ago
| |
| 19:00 | <vagrantc> and something's hosed my LXDE :(
| |
| 19:04 | alkisg: i know i've tested LDM_SESSION forcing a session recently...
| |
| 19:04 | alkisg: but if it fails to find the forced session, it will fallback to the defaults
| |
| 19:05 | <alkisg> OK I can ignore the other source then :)
| |
| 19:05 | help2man -s 8 -N --version-string 5.4.0 server/ltsp-update-sshkeys -o /tmp/ltsp-update-sshkeys.8 && man /tmp/ltsp-update-sshkeys.8
| |
| 19:05 | * alkisg wishes he knew that before spending time in manpages :) | |
| 19:05 | <vagrantc> alkisg: i can test again
| |
| 19:06 | alkisg: so, with all the sourced files ... how do we get our scripts to run?
| |
| 19:06 | do they source full paths or relative paths?
| |
| 19:07 | that was what killed my ability to try that before.
| |
| 19:08 | <alkisg> The usage doesn't/shouldn't need sourced files, except for ltsp-build-client... we could make some special case in his plugin sourcing code
| |
| 19:09 | ...we'll need some restructuring :-/
| |
| 19:09 | <vagrantc> and then VENDOR=Ubuntu ltsp-build-client won't obviously have the right manpage on Debian ... but that's an unusual enough case folks will probably cut us slack :)(
| |
| 19:09 | alkisg: restructuring ... not now! not now!
| |
| 19:09 | <alkisg> Nope, don't worry :D
| |
| 19:14 | <vagrantc> alkisg: putting LDM through it's paces now with the LDM_DESKTOP, LDM_DEFAULT_DESKTOP and soon LDM_SESSION testting
| |
| 19:14 | lefteris_nik has joined IRC (lefteris_nik!~Lefteris@ppp141237208190.dsl.hol.gr) | |
| 19:20 | <vagrantc> alkisg: ok, so LDM_SESSION isn't overriding the session- you can override with selectingg from the menu.
| |
| 19:20 | <alkisg> That should be fixed in the greeter, right?
| |
| 19:20 | <vagrantc> alkisg: and if that's the case, should maybe rename LDM_DEFAULT_DESKTOP to LDM_DESKTOP and LDM_DESKTOP to LDM_FORCE_DESKTOP ?
| |
| 19:21 | <alkisg> I like that better
| |
| 19:21 | Most people would want to set the default, not force it
| |
| 19:21 | <vagrantc> right
| |
| 19:22 | <alkisg> vagrantc: but LDM_SESSION currently overrides the user's .dmrc
| |
| 19:22 | So in any case we do need to fix the greeter
| |
| 19:22 | <vagrantc> alkisg: didn't for me.
| |
| 19:22 | alkisg: or hmm ... let me check
| |
| 19:23 | alkisg: oh, you're right ... it overrides ~/.dmrc
| |
| 19:23 | that seems buggy to me.
| |
| 19:24 | LDM_FORCE_SESSION (or LDM_SESSION_FORCE) could be implemented that way.
| |
| 19:25 | alkisg: ok, i'm going to rename LDM_DESKTOP to LDM_DESKTOP_FORCE and LDM_DEFAULT_DESKTOP to LDM_DESKTOP ... and maybe implement LDM_SESSION_FORCE, and try and get LDM_SESSION to not override ~/.dmrc ... ?
| |
| 19:25 | alkisg: or do you prefer LDM_FORCE_DESKTOP ?
| |
| 19:26 | <alkisg> vagrantc: no, LDM_DEFAULT_SESSION shouldn't override the user's dmrc
| |
| 19:26 | (currently)
| |
| 19:26 | so after the rename, LDM_SESSION will be fine, the problem will be in LDM_DEFAULT_SESSION
| |
| 19:26 | komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Quit: Leaving.) | |
| 19:26 | <alkisg> ...which will need to be fixed in the greeter
| |
| 19:26 | <vagrantc> LDM_FORCE_SESSION
| |
| 19:26 | <alkisg> Sorry, yes
| |
| 19:26 | <vagrantc> or LDM_SESSION_FORCE ?
| |
| 19:27 | FORCE_SESSION makes more sense in english, SESSION_FORCE sorts better.
| |
| 19:27 | i might have to do this later in the evening.
| |
| 19:27 | but the LDM_DESKTOP stuff seems to be workinng well.
| |
| 19:28 | <alkisg> LDM_FORCE_SESSION
| |
| 19:28 | (no strong preference though)
| |
| 19:31 | <vagrantc> ok.
| |
| 19:31 | <alkisg> vagrantc: what handles the translations that use eval_gettext? Is support for it embedded in some of the tools we use? ...why didn't they use a smaller function name, like `_ "text"` or $(_ "text") instead?! :(
| |
| 19:32 | <vagrantc> oh, there's already an LDM_DEFAULT_SESSION
| |
| 19:32 | <alkisg> vagrantc: yes, and it should be working fine, that's what I was trying to say
| |
| 19:32 | <vagrantc> alkisg: which tools are you talking about?
| |
| 19:32 | <alkisg> vagrantc: the ones that generate the .po files
| |
| 19:32 | That parse the source and extract the strings
| |
| 19:32 | <vagrantc> alkisg: in ldm or ltsp?
| |
| 19:32 | <alkisg> ltsp, in any shell file
| |
| 19:33 | E.g. ltsp-build-client --extra-help is localized
| |
| 19:33 | Because it uses eval_gettext to translate the options
| |
| 19:33 | ...but I'm wondering which tool reads our source code and extracts the text to translate from the eval_gettext parameters
| |
| 19:34 | <vagrantc> alkisg: oh, that was ax nightmare to implement ...
| |
| 19:34 | alkisg: look at po/Makefile
| |
| 19:35 | GETTEXTFILES
| |
| 19:35 | $(DOMAIN).pot
| |
| 19:35 | <alkisg> Ah, xgettext -L shell
| |
| 19:35 | <vagrantc> yup
| |
| 19:36 | alkisg: we did some insanity in order to generate the gettext-able commandline options from plugins.
| |
| 19:36 | alkisg: i haven't touched it since.
| |
| 19:36 | 2006
| |
| 19:36 | <alkisg> vagrantc: it'd be nice to have it for the other tools too
| |
| 19:37 | cat <<EOF
| |
| 19:37 | -b, --base $(_ "The LTSP base")
| |
| 19:37 | EOF
| |
| 19:37 | That's the syntax I'd like to have, but if eval_gettext is a standard.. :-/
| |
| 19:38 | <vagrantc> alkisg: experiment and see if it still works
| |
| 19:38 | alkisg: i do recall having issues with _
| |
| 19:40 | <alkisg> Or even $(_ "File %s does not exist." "$file") - which isn't usual in shell, but it's what other language use, and what translators are used to
| |
| 19:41 | <vagrantc> sure
| |
| 19:41 | <alkisg> The _() function is easy to implement, the difficult is the xgettext part
| |
| 19:42 | <vagrantc> alkisg: what if LDM_SESSION didn't touch ~/.dmrc at all ?
| |
| 19:43 | <stgraber> alkisg: don't we already have something like that in ldm-trunk? I thought we had translated shell in there
| |
| 19:43 | <alkisg> stgraber: haven't look, will check about it
| |
| 19:43 | vagrantc: let's talk with DEFAULT and FORCE in order to not get confused by the old/new names
| |
| 19:43 | <vagrantc> i think only the C code in ldm is translated
| |
| 19:43 | <stgraber> alkisg: apparently at least ltsp-cluster-info is translated with the right xgettext magic in the makefiles
| |
| 19:44 | <vagrantc> alkisg: i want to drop default
| |
| 19:44 | <alkisg> vagrantc: err why?
| |
| 19:44 | <vagrantc> alkisg: because i think DEFAULT should be assumed, and FORCE should be specified.
| |
| 19:44 | <stgraber> vagrantc: nope, we have some translated rc.d hooks and ltsp-cluster-info is also translated (po/rc.d and po/ltsp-cluster-info)
| |
| 19:45 | <alkisg> vagrantc: agreed about the names, I just wasn't sure when you said LDM_SESSION if you were talking about its old meaning or its new meaning
| |
| 19:45 | <vagrantc> i.e. LDM_SESSION and LDM_DESKTOP behave like defaults, and LDM_FORCE_SESSION and LDM_FORCE_DESKTOP appropriately.
| |
| 19:45 | <alkisg> That's why I proposed that we talk with DEFAULT and FORCE, but of course you won't commit the DEFAULT word anywhere
| |
| 19:45 | <vagrantc> got it.
| |
| 19:46 | alkisg: so, i don't think FORCE should ever save to ~/.dmrc
| |
| 19:46 | <alkisg> vagrantc: and when would we write to .dmrc? Only when the user selects it from the menu?
| |
| 19:46 | Then we'd need a third variable passed from ldm
| |
| 19:47 | I agree with the concept, not sure about the necessary code changes...
| |
| 19:47 | <vagrantc> and LDM_DESKTOP should be written to ~/.dmrc, but LDM_(default)_SESSION shouldn't.
| |
| 19:47 | <alkisg> Ah
| |
| 19:47 | <vagrantc> wait, no ... LDM_(default)_DESKTOP shouldn't either ... hrm.
| |
| 19:47 | <alkisg> I think that LDM_DESKTOP shouldn't be written either... ^ :)
| |
| 19:48 | <vagrantc> i've just confused myself, and need to head soon ... i'll have to work on more of this later.
| |
| 19:49 | <alkisg> stgraber: ltsp-cluster appears to be using eval_gettext too, I was looking if we could use a shorter name in order to for things like those to be more readable:
| |
| 19:49 | usage() {
| |
| 19:49 | cat <<EOF
| |
| 19:49 | -a, --arch $(_ "The architecture of the chroot.")
| |
| 19:49 | EOF
| |
| 19:49 | }
| |
| 19:50 | ...but xgettext won't detect $(_ ) I believe
| |
| 19:53 | Hehe bash -D, handy!!!
| |
| 19:56 | <vagrantc> will hopefully tweak ldm later and upload ... gotta head out for a while.
| |
| 20:00 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 20:37 | andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net) | |
| 20:49 | uskerine has left IRC (uskerine!~uske@80.30.244.131, Ping timeout: 260 seconds) | |
| 21:06 | <alkisg> OK, here's my proposal for translations: http://paste.ubuntu.com/1022071/
| |
| 21:09 | echo `_ 'Automatic login in %d seconds' 10`
| |
| 21:09 | At least visually it seems quite good
| |
| 21:19 | litlebuda has joined IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt) | |
| 21:21 | ricotz has left IRC (ricotz!~rico@unaffiliated/ricotz, Quit: Ex-Chat) | |
| 21:31 | uskerine has joined IRC (uskerine!~uske@80.30.244.131) | |
| 21:42 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 252 seconds) | |
| 21:49 | andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds) | |
| 22:07 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 22:17 | uskerine has left IRC (uskerine!~uske@80.30.244.131, ) | |
| 22:20 | sideffect has joined IRC (sideffect!sideffect@gateway/shell/bshellz.net/x-bvosoxjrjdvdykxh) | |
| 22:26 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving) | |
| 23:15 | lefteris_nik has left IRC (lefteris_nik!~Lefteris@ppp141237208190.dsl.hol.gr, Remote host closed the connection) | |