--- Day changed

--- Log opened Tue Jul 01 00:00:03 2003
00:28 -!- PiAf` [~piaf@212.37.221.32] has joined #uml
00:28 < PiAf`> hi
00:34 < Dave\\> hrm, arthur, can you let me know how it goes? I'm interseted in openMosix ttoo
00:40 < david> don't even bother trying to run UML over mosix
00:40 < david> it's too high I/O to be useful
00:41 < Dave\\> is there any kind of clustering I can do w/ UMLs?
00:41 < Dave\\> I will be having a lot of UMLs and it would be nice if they could share resources between hosts
00:41 < david> Dave\\: not really
00:42 < david> Dave\\: maybe with gbit ethernet, but that's still pushing it
00:43 < Dave\\> even with oMFS? because I do have gig ethernet for this
00:43 < Dave\\> :/
00:45 < david> Dave\\: maybe - Depends what Mosix thinks of UML's I/O usage
01:39 -!- Lathiat [lathiat@130.95.13.25] has quit [Quit: Lost terminal]
01:41 -!- Lathiat [lathiat@seven.sixlabs.org] has joined #uml
01:43 < arthur> the skas openmosix patch seems to break the skass patch
01:43 < Lathiat> hah
01:44 < Lathiat> gimme the url ill see if i can munge it for you?
01:44 < Lathiat> actually i gota run, shoot it ot lathiat@sixlabs.org if u still want me to slook at it
02:32 -!- ido [~Ido@212.150.75.108] has joined #uml
02:59 < ido> hmm
02:59 < ido> guys here ?
02:59 < caker> hello ido
03:00 < ido> how're you doing ?
03:00 < ido> how's linnode doing ? :)
03:00 < caker> Going well .. thanks
03:00 < ido> eh.
03:00 < ido> great.
03:00 < caker> what's shakin
03:02 < ido> anyhow, i'm not sure it has to do with this, but the problem that after booting the UML it doesn't show the main console (only attached VC's on xterm windows), happend only after i ptrace pactched it (mm->dumpable = 1;). I dont think it has to do with this, but its quite wierd.
03:02 < caker> whats your command line?
03:03 < ido> ./uml ubd0=fs con=pts con0=fd:0,fd:1
03:04 < ido> what does fd:0 and fd:1 refer to ?
03:04 < ido> s/does/do
03:04 < caker> stdin and stdout
03:04 < caker> file descriptor 1 ...
03:04 < caker> hmm
03:04 < caker> do you see it boot all the way, but just con't get a login prompt?
03:04 < ido>  file descriptor 0 is stdin and fd 1 is stdout ?
03:05 < ido> i see the whole boot session
03:05 < ido> but the output stops
03:05 < caker> try adding devfs=nomount
03:05 < ido> right after it should give me a login prompt
03:05 < caker> because your /etc/inittab might reference devfs devices, or non-devfs devices
03:06 < ido> welp, it worked ok in the past
03:06 < ido> just stopped working for some reason
03:06 < caker> but you recompiled and turned something on/off :-)
03:06 < ido> trying no-devfs as we speak
03:07 < ido> hope it works :)
03:07 < ido> nope, stops right after " * Starting local...  [ ok ]"
03:08 < caker> then maybe you need devfs and it isn't compiled in
03:08 < caker> check your .config
03:08 < ido> it is :)
03:08 < caker> what's in your /etc/inittab for getty's 
03:08 < caker> in the uml filesystem
03:09 < ido> lemme check
03:09 < ido> welp, using gentoo, and it worked before
03:13 < ido> c1:12345:respawn:/sbin/agetty 38400 tty1 linux
03:13 < ido> c2:12345:respawn:/sbin/agetty 38400 tty2 linux
03:13 < ido> seems ok
03:13 < caker> no devfs there ...
03:13 < caker> and no tty0
03:14 < caker> con0 on the command prompt is tty0 inside uml
03:14 < ido> hmm
03:14 < caker> so add a duplicate line but c0 and tty0
03:14 < ido> so i should point those to con1=fd:0,fd:1 ?
03:15 < caker> that just sets it up, then you have to tell the uml kernel to use that as it's console
03:16 < ido> weird, it worked before without that ;p
03:17 < caker> nite - good luck ido
03:18 < ido> goodnight.
03:28 -!- nxtw [nxtw@68.76.176.193] has quit [Quit: Peace and Protection 4.22]
03:35 -!- ido [~Ido@212.150.75.108] has quit [Ping timeout: 496 seconds]
03:42 -!- ido [~Ido@212.150.75.108] has joined #uml
03:42 < ido> still experiancing that problem
04:48 -!- revenger [revenger@p508B17BF.dip.t-dialin.net] has joined #uml
04:51 -!- revenger_ [revenger@80.139.59.220] has quit [Ping timeout: 488 seconds]
06:28 < Dave\\> ido
06:28 < Dave\\> do you have a 
06:28 < Dave\\> c0:12345:respawn:/sbin/agetty 38400 tty0 linux
06:28 < Dave\\> ?
06:29 < Getty> <highlight>
06:29 < Dave\\> hi Getty
06:29 < Dave\\> :p
06:29 < Getty> hi dave :)
06:29 < Dave\\> that
06:30 < Dave\\> that's what you get for using a nick like that
06:30 < Dave\\> ;)
06:30 < Getty> oh, after 8 years.....
06:30 < Getty> its nothing special
06:30 < Getty> but you come into talk ;)
06:30 < Dave\\> I never hear people accidentally say Dave\\
06:30 < Dave\\> hehe
06:30 < Dave\\> how are you?
06:30 < Getty> anyway what is "Dave\\" for a nick? ;-)
06:30 < Getty> fine
06:31 < Getty> i'm in office since 1 hour and i wanna home
06:31 < Dave\\> :P
06:31 < Dave\\> ok I think I am going to have breakfast.. 06:27:20 AM
06:31 < Getty> hehe
06:31 < Getty> what country?
06:31 < Dave\\> USA
06:31 < Getty> ah :)
07:31 -!- yeti [~yeti@pD950B034.dip.t-dialin.net] has joined #uml
08:02 -!- DnsInfector [~DnsInfect@ARennes-204-1-3-88.w193-252.abo.wanadoo.fr] has joined #uml
09:06 -!- litost [~sombitch@phynp6.phy-astr.gsu.edu] has joined #uml
09:50 -!- DnsInfector_ [~DnsInfect@ARennes-204-1-12-84.w81-53.abo.wanadoo.fr] has joined #uml
09:56 -!- DnsInfector [~DnsInfect@ARennes-204-1-3-88.w193-252.abo.wanadoo.fr] has quit [Ping timeout: 490 seconds]
10:00 -!- DnsInfector__ [~DnsInfect@ARennes-204-1-14-44.w81-248.abo.wanadoo.fr] has joined #uml
10:08 -!- DnsInfector_ [~DnsInfect@ARennes-204-1-12-84.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 490 seconds]
10:37 -!- shanti [shanti@157.182.197.35] has joined #uml
10:40 -!- AquaJo [~torbofh@217.228.207.194] has joined #uml
10:43 -!- arthur [~arthur@adsl-67-120-107-148.dsl.snfc21.pacbell.net] has quit [Quit: Client Exiting]
12:11 -!- DnsInfector__ [~DnsInfect@ARennes-204-1-14-44.w81-248.abo.wanadoo.fr] has left #uml [Client exiting]
12:19 < david> morning
12:32 < ido> morning to you too
12:34  * AquaJo says good night in a few minutes ... :-)
12:41 < Getty> oh its about 18:41 here
12:43 < AquaJo> dito, but I have to get up at 6 o'clock an I'll go out later
13:14 -!- ido [~Ido@212.150.75.108] has quit [Read error: Connection reset by peer]
13:18 -!- ido [~Ido@212.150.75.108] has joined #uml
13:18 < ido> hmm.
13:21  * caker has been listening to jack hammers outside his window for two days **goes insane**
13:28 -!- AquaJo [~torbofh@217.228.207.194] has quit [Quit: Die Schwierigkeit, mit den meisten Leuten umzugehen, besteht darin, zu ihnen gleichzeitig ehrlich  und höflich zu sein - Heller, André]
15:18 -!- bch [~db@ppp-217-133-208-208.cust-adsl.tiscali.it] has joined #uml
16:08 -!- DnsInfector [~DnsInfect@81.248.224.44] has joined #uml
16:35 -!- Lathiat [lathiat@seven.sixlabs.org] has quit [Remote host closed the connection]
16:42 -!- bch [~db@ppp-217-133-208-208.cust-adsl.tiscali.it] has left #uml [Client Exiting]
16:53 -!- Lathiat [lathiat@seven.sixlabs.org] has joined #uml
16:59 < Getty> boar
16:59 < Getty> shit
17:00 < Getty> what was the command line for mounting tmpfs again?
17:00 < Getty> i can
17:00 < Getty> 't find it on the page again...
17:03 < Getty> AH! got it...
17:04 < Getty> just a little thinking ;)
17:16 < Getty> cool UML running again
17:16 < Getty> should setup it at the init.d ;)
17:19 -!- litost [~sombitch@phynp6.phy-astr.gsu.edu] has quit [Quit: ERC v2.91 $Revision: 1.239 $ (IRC client for Emacs)]
17:20 -!- DnsInfector [~DnsInfect@81.248.224.44] has left #uml [Client exiting]
17:45 -!- ido [~Ido@212.150.75.108] has quit [Ping timeout: 496 seconds]
18:00 -!- shanti [shanti@157.182.197.35] has quit [Quit: Client Exiting]
18:25 -!- yeti [~yeti@pD950B034.dip.t-dialin.net] has quit [Quit: Client exiting]
19:13 -!- Z-Wing [zedders@zanzar.net] has quit [Ping timeout: 490 seconds]
19:23 -!- TheLinuxAngel [~cameron@210.54.58.70] has joined #uml
19:23 < TheLinuxAngel> Hola all.
19:24 < TheLinuxAngel> I'm about to create a virtual network (using uml_switches and routers) for experimentation with Multicast.
19:25 < TheLinuxAngel> The idea is to build a network my students can use for learning multicast programming (I really want to throw in some routers to make it more interesting.
19:26 < TheLinuxAngel> Question: Does anyone know if uml_switch handles IGMP snooping?
19:29 < TheLinuxAngel> Hmmm, a simple grep on the uml_router source for multicast would suggest not (port.c:    /* no cache or broadcast/multicast == all ports */)
19:30 < caker> TheLinuxAngel: can you use a bridge and use an UML as a gateway/router?
19:31 < TheLinuxAngel> Would that be any better? I don't think Linux does IGMP snooping either.
19:32 < caker> Not sure about IGMP, but using a bridge on the host makes everything appear like a normal network connection -- no special routes/setups inside UML necessary
19:32 < caker> Although the bridge does "switch" in some ways (except for broadcast traffic)
19:32 < TheLinuxAngel> I don't care about UML to host setups for this, I just want a totally virtual network.
19:33 < caker> ahh
19:33 < caker> That's cool too - just use a bridge and don't add the host to it :-)
19:33 < TheLinuxAngel> why???
19:33 < caker> or multiple bridges - to span the UML's together
19:34 < TheLinuxAngel> I'd prefer to use uml_switch generally, its easier.
19:34 < caker> word
19:34 < TheLinuxAngel> bongo
19:34 < TheLinuxAngel> its a word ;^)
20:13 < david> uml_switch can cause problems
20:14 < Pahan> uml_switch is such a horrible evil mess.
20:22 < TheLinuxAngel> In what way(s)?
20:23 < TheLinuxAngel> (can it cause problems)
20:31 < Pahan> Mmmm.
20:31 < Pahan> It might.
20:31 < Pahan> Who knows?
20:32 < Pahan> It doesn't even handle partial recv returns on the control socket.
20:32 < david> TheLinuxAngel: if the uml_switch dies, you have to remove then add all the eth devices on the UMLs again
20:32 < TheLinuxAngel> Hmmm, a rewrite sounds in order.
20:32 < Pahan> david: Oh, yeah, what is up with that?
20:33 < Pahan> david: UML network subsystem cannot handle disconnections from the switch daemon control socket.
20:33 < TheLinuxAngel> david: I've had plenty of students complain about switch deaths.
20:33 < Pahan> david: Also, the stupid protocol writes C structs into the network. That's ridiculous.
20:33 < TheLinuxAngel> I thought it writes ethernet packets
20:34 < Pahan> The data communication, yes.
20:34 < Pahan> Control protocol doesn't.
20:34 < TheLinuxAngel> Oh
20:34 < Pahan> It's an incredible way to make your software break dependent on platform and C compiler options.
20:35 < TheLinuxAngel> Sounds like an intreging project. Pity I'm snowed under atm. Perhaps after the second semester has finished...
20:36 < Pahan> I am rewriting the daemon in Python, but that won't help much -- the protocol is still the same, and I might introduce not unnoticeable performance issues.
20:37 < TheLinuxAngel> Oh, what features will it include?
20:38 < Pahan> Mostly a flexible configuration file for running several switches using same process. Perhaps utilization statistics and such, if I ever need that.
20:39 < TheLinuxAngel> VLAN? IGMP Snooping? SNMP?
20:39 -!- jdike [~jdike@h69-21-249-87.69-21.unk.tds.net] has joined #uml
20:39 < Pahan> Ugh.
20:39 < Pahan> Does anybody need that?
20:39 < Pahan> jdike: I'd like to scream at you because of the protocol uml_switch uses.
20:39 < TheLinuxAngel> VLAN would be useful for teaching network management.
20:40 < jdike> Pahan: what would be the problem?
20:40 < Pahan> jdike: Well, two things.
20:40 < Pahan> jdike: First, it uses C structs for control protocol. That's really bad.
20:40 < Pahan> jdike: Second, UML can't recover from control socket disconnection. That's annoying.
20:40 < TheLinuxAngel> very
20:41 < jdike> Pahan: neither is a protocol issue
20:41 < jdike> Pahan: both are bugs
20:41 < Pahan> jdike: Oooh.
20:42 < Pahan> jdike: So umm. Could those be fixed at some point? ;-)
20:42 < jdike> Pahan: hold on...
20:44 < jdike> Pahan: The structures are u32 and char (except for one enum)
20:44 < jdike> Pahan: that's not C compiler dependent
20:45 < Pahan> jdike: Tsk, sockaddr_un is compiler dependent and is a pain in the butt to get right.
20:45 < jdike> Pahan: in what language?
20:46 < Pahan> jdike: Python. Well, C as well, since my own test program (without any compiler switches) thinks that sockaddr_un is different from what UML sends.
20:46 < Pahan> jdike: UML does not align the path char array -- it pads it instead.
20:46 < jdike> Pahan: hmmm
20:46 < Pahan> That's Debian-supplied executable.
20:47 < Pahan> jdike: I don't know how the OS handles this whole mess, but it's really freaky.
20:47 < jdike> Pahan: Off the top of my head, it seems that sockaddr_un should be the same from compiler to compiler
20:47 < Pahan> Indeed.
20:48 < jdike> Pahan: coz that gets passed to the kernel
20:48 < Pahan> Hrm.
20:48 < Pahan> Maybe I am wrong about the alignment, and it is padded in both cases.
20:48 < jdike> Pahan: so that looks like a compiler (or code) problem
20:48 < Pahan> jdike: But anyway, if there are any plans to extend uml_switch to work over other sorts of sockets, there will be problems.
20:49 < TheLinuxAngel> Pahan: Did you properly zero the entire structure?
20:49 < Pahan> This stuff might be the same across one machine, but you can't just send sockaddr_* around via the network.
20:49 < Pahan> TheLinuxAngel: I don't have anything to zero -- this is not C.
20:49 < TheLinuxAngel> Right
20:49  * Pahan moves the padding.
20:50 < TheLinuxAngel> Too bad you can't use something like tcpdump on a unix socket.
20:50 < Pahan> Heh.
20:50 < Pahan> Write a kernel module ;-)
20:50 < jdike> Pahan: it's a sockaddr_un on purpose
20:50  * TheLinuxAngel wonders about gdb
20:50 < Pahan> jdike: Define the purpose.
20:51 < jdike> Pahan: making it a sockaddr_anything_else would require that I add authentication to the protocol
20:51 < jdike> Pahan: sockaddr_un is local by definition
20:51 < jdike> Pahan: so if you want remote mconsole access, you do it over ssh, and I don't have to deal with authentication
20:52 < Pahan> jdike: The protocol does not exclude the possibility of authentication and/or using other kinds of sockets. Why not avoid relying on platform-specific behavior from the start?
20:52 < TheLinuxAngel> Passing structures over sockaddr_un isn't all that bad. Its a valid form of IPC.
20:53 < TheLinuxAngel> For instance, you can pass open file descriptors over sockaddr_un (passing credentials)
20:53 < Pahan> TheLinuxAngel: I have not yet decided whether that's an ugly hack that should be avoided or a useful feature.
20:53 < Pahan> TheLinuxAngel: I'll make up my mind when I see software that uses it.
20:53 < jdike> Pahan: UML uses it
20:53 < Pahan> jdike: Really?
20:53 < Pahan> Neat.
20:54 < Pahan> jdike: For what purposes?
20:54 < jdike> Pahan: it's a useful feature as far as I'm concerned
20:54 < jdike> Pahan: uml_net opens descriptors as root, then passes them to UML for the actual IO
20:54 < Pahan> Oh.
20:55 < jdike> Pahan: that allows a setuid helper to exist only to open the descriptor and means it's not available to be exploited the rest of the time
20:55 < jdike> Pahan: attaching consoles to host portals uses it as well
20:55 < Pahan> jdike: When I see "suid", I usually scream and run away, but this seems to be a good use case.
20:56 < jdike> Pahan: a descriptor attached to telnetd is passed from port_helper to the UML driver over a unix socket
20:56 < Pahan> jdike: What about the second thing, reconnecting to the switch? Couldn't this be done when interface goes up?
20:57 < jdike> Pahan: that's been something I've known about for a while, just haven't done anaything about it
20:57 < TheLinuxAngel> There are many good uses for suid, and in a well-designed program, they are very small pieces of code with a lot of input validation.
20:57 < Pahan> The whole thing is nicely parallel to ethernet link-sense going up and down.
20:58 < TheLinuxAngel> jdike: Any idea why the switch crashes?
20:58 < Pahan> TheLinuxAngel: Speaking of the switch thing, I will only do additional work on it if there are people interested in using it.
20:59 < Pahan> TheLinuxAngel: If you find somebody who needs all the vlan and other fancy stuff, great.
20:59 < jdike> TheLinuxAngel: you using the latest one?
20:59 < jdike> TheLinuxAngel: I fixed a segfault a month or so ago
20:59 < TheLinuxAngel> A very recent on, I think
20:59 < TheLinuxAngel> Great
21:00 < david> hello
21:00 < jdike> Pahan: there is interest in vlan
21:00 < jdike> hi david
21:00 < Pahan> jdike: Is that from same people who can suffer an additional dependency and possibly, latency?
21:01 < TheLinuxAngel> Pahan: I think the actual switch should be done in C, with a management frontend (ncurses preferably, so it will work in a screen session), in Python or Perl
21:01 < david> management frontend?
21:01 < david> wtf?
21:01 < Pahan> TheLinuxAngel: I'll C programming for people who like doing it.
21:01 < Pahan> s/C/leave C/
21:01 -!- jdike [~jdike@h69-21-249-87.69-21.unk.tds.net] has quit [Quit: Leaving]
21:01 < TheLinuxAngel> david: for the switch
21:01 < david> TheLinuxAngel: why does it need a frontend?
21:02 -!- jdike [~jdike@69.21.249.87] has joined #uml
21:02 < TheLinuxAngel> To manage it (have a manageable switch)
21:02 < Pahan> david: If it ever includes any additional feature, it will need a way to reconfigure it on the fly.
21:02 < Pahan> s/feature/features/
21:02 < jdike> Pahan: there is definite specific interest in vlan
21:02 < david> so write a simple command line tool to do it
21:02 < david> I don't need a ncurses thing to setup vlans
21:03 < jdike> bbiab
21:03 < Pahan> jdike: I'll see if I can include that easily.
21:03 < Pahan> david: The exact nature of the frontend is irrelevant.
21:03 < TheLinuxAngel> david: could have both.
21:03 < TheLinuxAngel> So long as the protocol is well designed.
21:03 < Pahan> Whether it is curses, native Windows GUI or a Java applet with droolworthy pictures.
21:03 < david> TheLinuxAngel: true
21:04  * TheLinuxAngel crosses fingers at the mention of Java (stay back!)
21:04  * Pahan waves at TheLinuxAngel with Java-on-a-stick.
21:05  * TheLinuxAngel slaps Pahan with a fist full of Perl
21:05 -!- Z-Wing [zedders@zanzar.net] has joined #uml
21:05 < Pahan> Heh, Perl.
21:05 < TheLinuxAngel> Love it
21:05  * Pahan laughs and mocks.
21:08 < TheLinuxAngel> You've never actually used Perl properly, have you.
21:09 < Pahan> I have been happily Perl-free.
21:09 < TheLinuxAngel> free/naive... whatever
21:09 < Pahan> I prefer to laugh at it from a good distance.
21:10 < TheLinuxAngel> I write in both Perl and Python, they both have a definate set of apps they are well suited to.
21:10 < Pahan> What applications is Perl good for?
21:11 < TheLinuxAngel> Read about formats for instance. Instant power
21:11 < Pahan> Mmmm, URL?
21:11 < TheLinuxAngel> Database, SNMP, Reports, things closer to scripts and small apps
21:12 < Pahan> Ugh, did Perl figure out how to do event-driven asynchronous networking yet?
21:12 < TheLinuxAngel> Whereas Python has better OO, and so is suited to larger apps.
21:12 < TheLinuxAngel> No reason why not, SIGIO is just another signal.
21:13 < Pahan> HAHAHAHAHA
21:13 < Pahan> Sorry.
21:13 < Pahan> SIGIO is a couple of levels of abstractions away from SNMP.
21:13 < TheLinuxAngel> Oh, you're talking about SNMP?
21:13 < Pahan> Well, any sort of network application.
21:14 < Pahan> Particularly ones where forking isn't the answer.
21:14 < TheLinuxAngel> What, like C's select?
21:14 < Pahan> No, like a level above select(2)
21:25 -!- TheLinuxAngel [~cameron@210.54.58.70] has quit [Quit: Gotta work]
21:26  * Pahan stands on his head.
21:47 < caker> evening all
21:51 < mistik1> re
22:05 < jdike> back
22:07 < Pahan> jdike: Does uml_switch go into hub mode when its MAC address table overflows or does it not have an upper bound?
22:07 < Pahan> Does it expire MAC addresses?
22:08 < jdike> Pahan: it times out MACs
22:08 < jdike> Pahan: it doesn't overflow, it will allocate memory until that runs out
22:08  * Pahan conjures an arbitrary limit.
22:09 < Pahan> What's the timeout, though?
22:10 < jdike> Pahan: don't know offhand
22:11  * Pahan looks.
22:12 < jdike> Pahan: 100 secs
22:12 < jdike> Pahan: GC_EXPIRE in hash.c
22:13 < Pahan> Thanks.
22:29 < jdike> time to get going...
22:29 -!- jdike [~jdike@69.21.249.87] has quit [Quit: Leaving]
--- Log closed Wed Jul 02 00:00:00 2003