Back
[01:32:46] <jmk_away> cradek: on the subject of security and run-in-place: I think they are mutually incompatible
[01:33:21] <jmk_away> if you can compile without root privliges (a neccessity IMO, in keeping with linux tradition) then you can replace the source for one of the kernel modules with a trojan
[01:33:40] <jmk_away> then compile, and run in place, and presto, you have a trojan kernel module - the system is cracked
[01:33:51] <jmk_away> but I'm not willing to give up run-in-place
[01:34:11] <jmk_away> mostly because as a developer it saves a crapload of time and lets me have multiple versions
[01:34:54] <jmk_away> with most programs it is the "make install" step that provides security. You need to be root to do that, and as root you should know what you are installing
[01:42:30] <jmk_away> hi
[01:43:09] <jmk_away> run-in-place and security are mutually incompatible
[01:43:19] <jmk_away> (unfortunately)
[01:43:45] <jmk_away> I want to keep run-in-place, for one thing it lets me have multiple versions at once
[01:44:37] <jmk_away> but if you can compile without being root (a must IMO) then you could replace the source for some module with a trojan, compile, and run in place, and presto, you have a cracked system
[01:45:38] <jmk_away> so run-in-place should require sudo (or su -c)
[01:46:02] <jmk_away> that way, security of run-in-place depends on the system's sudo policy. If you have crappy sudo security, then so be it
[01:50:26] <jepler> if run-in-place is for developers only, that sounds fine to me
[01:50:50] <jmk_away> but can we make it work
[01:51:31] <jmk_away> "sudo emc" lets the run script run as root, I guess that will pass on to module-helper (because it won't be setuid when doing run-in-place)
[01:51:35] <jepler> though you should also be able to ./configure --prefix=/usr/emc-20060129 too
[01:52:32] <jmk_away> then make, and sudo make install?
[01:52:54] <jepler> yes
[01:53:26] <jmk_away> and then you need to explicitly give a path when you run it? (to run the one you want)...
[01:53:33] <jepler> yes
[01:54:17] <jmk_away> and the installer might make icons for multiple versions...
[01:54:18] <jepler> ./configure --prefix=`pwd` --bindir=`pwd` && make && sudo make install ?
[01:54:37] <jepler> or else run in place could require 'sudo make set-permissions'?
[01:54:52] <jmk_away> ahh, now that I like
[01:55:14] <jmk_away> it would make halcmd and module-helper setuid, right?
[01:55:50] <jmk_away> btw, I think I like the idea of having halcmd invoke module-helper, so halcmd no longer needs to be setuid
[01:57:20] <jmk_away> putting all insmod security in one place seems like a good idea
[02:00:34] <jepler> yes, yes
[02:01:18] <jmk_away> you ever see this before:
[02:01:20] <jmk_away> cvs update: move away `include/.cvsignore'; it is in the way
[02:01:21] <jmk_away> C include/.cvsignore
[02:02:27] <jmk_away> got that for half a dozen directories
[02:03:53] <jmk_away> oh, I see - you added the .cvsignore files
[02:04:02] <jmk_away> and they conflict with ones that I already created here
[02:04:34] <jmk_away> nefs
[02:07:20] <jepler> you wrote some .cvsignore files but didn't add them? I wonder if everyone had done that ..
[02:07:26] <jepler> did I break a rule by adding the .cvsignores or something?
[02:07:41] <jmk_away> I'm unaware of any rule
[02:07:55] <jmk_away> I had some local cvsignores
[02:08:18] <jmk_away> but in hindsight it makes sense to commit them
[02:09:47] <jmk_away> I'll delete my local ones and cvs up again, should solve the problem
[02:29:39] <fenn> * fenn pokes his head in and looks around.
[02:29:54] <fenn> logger_devel: bookmark
[02:29:54] <fenn> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-01-30#T02-29-54
[02:39:07] <cradek> darn, I missed everyone.
[02:39:49] <cradek> obviously you guys are right about how compiling should not require sudo
[02:40:03] <cradek> I don't know what I was thinking
[02:40:19] <cradek> usually it takes two passes for me to do something reasonable, the first turns out goofy
[02:41:32] <cradek> I think we need to be watching for whether run-in-place is more trouble than it's worth... I'm not sure it is yet, but those scripts really are complicated.
[02:42:24] <cradek> for instance look at "realtime"
[02:42:35] <cradek> it has to guess where several things are.
[02:42:48] <cradek> run-in-place might be bogus already (if you also have an installed version).
[02:43:31] <jepler> as for module_helper, why not drop root completely at the top of error(), just so I can worry about less code.
[02:44:05] <cradek> yeah that sure is more complex than I wanted, but I think all the output is needed.
[02:44:50] <cradek> is that setuid(getuid())?
[02:45:23] <jepler> yes, I think so
[02:47:35] <jepler> "dot" isn't used for anything anymore
[02:48:34] <cradek> right
[02:49:18] <jepler> I can attempt to insert rtapicheese.ko
[02:49:44] <cradek> I thought I fixed that
[02:49:54] <cradek> no, I fixed the "shorter" case
[02:49:56] <cradek> crap
[02:50:45] <SWP_Away> SWP_Away is now known as SWPadnos
[02:50:54] <jepler> do the modules ever end with something besides .ko?
[02:51:00] <SWPadnos> .o
[02:51:01] <cradek> yes
[02:52:10] <SWPadnos> this program is supposed to validate that any module to be loaded is of the form {acecptablePathName}/{acceptableModuleName}.{o,ko} right?
[02:52:35] <cradek> no
[02:52:38] <SWPadnos> oh ;)
[02:53:20] <cradek> {whitelisted path}{more stuff not including ..}/{whitelisted module}.extension
[02:53:32] <cradek> so whitelisted path = /usr/realtime
[02:53:44] <cradek> my system has /usr/realtime-2.6.12-magma/... which is fine
[02:54:23] <SWPadnos> ok. would a symlink on install make things easier?
[02:54:48] <cradek> not really, I don't think
[02:54:49] <SWPadnos> /usr/realtime-2.6.12-magma/ -> /usr/realtime
[02:55:03] <SWPadnos> or hte other way around
[02:55:11] <cradek> no, that defeats the purpose of naming it realtime-kernelversion
[02:55:20] <SWPadnos> ok
[02:55:20] <cradek> /lib/modules has the same problem
[02:55:27] <SWPadnos> true
[02:55:51] <jmk_away> if there is a symlink, it should point to realtime<kernel-version-that-is-running-right-now>
[02:55:54] <cradek> jepler: how do I fix rtapicheese? can you do it? I'm trying to figure out my ssh keys
[02:56:11] <SWPadnos> that would be a runscript possibility
[02:56:14] <cradek> jmk_away: some distribs used to do that for /lib/modules
[02:56:25] <cradek> SWPadnos: no, the script can't make symlinks in /usr!!
[02:56:30] <SWPadnos> cradek - try staring from the tail of the module name
[02:56:37] <SWPadnos> true - good idea ;)
[02:57:06] <jepler> cradek: I'm looking at it
[02:57:11] <cradek> thanks
[02:57:19] <cradek> seems I write a bug for every one I fix
[02:58:13] <SWPadnos> heh - you could get weird with strrev :)
[02:58:47] <cradek> SWPadnos: the goal is not "weird" here
[02:58:52] <SWPadnos> heh
[02:59:00] <cradek> it's to write a simple program with no bugs, which seems nearly impossible
[02:59:21] <SWPadnos> reverse the string, look for a leading "ok." or "o." - if not found error, else strip it off and continue
[02:59:34] <cradek> that's very lispy
[02:59:40] <jmk_away> I don't understand the problem with names
[02:59:48] <jmk_away> split the string at the last / and the last .
[02:59:56] <jmk_away> after the . must be either o or ko
[03:00:05] <jmk_away> between the slash and the dot must exactly match a whitelist name
[03:00:31] <SWPadnos> before the slash has no "..". and begins with a whitelisted path
[03:00:36] <cradek> yes, I think I agree that's the algorithm
[03:01:29] <jepler> since /usr/realtime is not under the control of the user, do we actually care that 'rtapicheese.ko' can be inserted?
[03:01:43] <cradek> jepler: yes, I think so
[03:01:47] <jmk_away> my thoughts exactly
[03:01:53] <SWPadnos> I agree
[03:01:56] <cradek> jepler: I think I want a real whitelist
[03:02:15] <jmk_away> that means anyone writing a new HAL module will need to edit the whitelist
[03:02:24] <cradek> jmk_away: yep
[03:02:37] <jmk_away> I have mixed feelings about that
[03:03:31] <jmk_away> if an attacker has write access to the directory, he can rename his trojan module to match a whitelisted name
[03:03:39] <jmk_away> so what does it get you?
[03:03:50] <jmk_away> the directory must be secure anyway, so trust the directory
[03:03:51] <cradek> if we don't have a whitelist, we're allowing the user to insert any module in /lib/modules or /usr/realtime...
[03:04:18] <SWPadnos> even one that might take down the machine
[03:04:35] <jmk_away> oh, you are talking about a legit module, but not one that is emc related
[03:04:35] <SWPadnos> just take out the n in the comparison - do a strcmp instead of strncmp
[03:04:53] <cradek> jmk_away: exactly
[03:05:03] <SWPadnos> (on line 94)
[03:05:07] <cradek> SWPadnos: that will compare the extension too
[03:05:18] <SWPadnos> strip off the extension - you can put it back later
[03:05:18] <cradek> SWPadnos: I'm sure jepler can get it right :-)
[03:05:18] <jmk_away> how about this:
[03:05:26] <jepler> cradek: you have too much faith in me
[03:05:32] <jmk_away> all HAL modules are in <somepath>/hal
[03:05:53] <SWPadnos> store a '\0' at the '.', then put it back after the comparison (or compare strlen as well as strncmp)
[03:05:58] <jmk_away> any module in <somepath>/hal can be installed, as well as whitelisted modules in <somepath>
[03:06:06] <jmk_away> the former handles HAL modules, and allows new ones
[03:06:21] <jmk_away> the latter handles rtapi.ko, and hal_lib.ko and the rtai modules
[03:06:37] <cradek> jmk_away: it has to insert all the rtai modules too
[03:06:59] <jmk_away> the latter handles rtapi.ko, and hal_lib.ko and the rtai modules ;-)
[03:07:23] <cradek> jmk_away: I do not think someone savvy enough to write a hal module is going to stumble over this whitelist for long. I don't see why we should compromise on the whitelist.
[03:08:06] <SWPadnos> how about this: (replacing line 94):
[03:08:14] <SWPadnos> if((strlen(module_whitelist[i]) == strlen(last_slash+1))
[03:08:16] <SWPadnos> && (!strncmp(last_slash+1, module_whitelist[i],
[03:08:17] <SWPadnos> strlen(module_whitelist[i]))))
[03:08:21] <jmk_away> I just like stuff to be self contained
[03:08:34] <jmk_away> examples:
[03:08:47] <SWPadnos> (or replace the last strlen with max(the two strlens))
[03:08:50] <jmk_away> writing new module = write code, add a line to the make file GOOD
[03:09:07] <jmk_away> add an NML message = write new code in 12 different files BAD
[03:09:16] <cradek> I know jmk
[03:09:36] <cradek> I normally agree
[03:09:40] <jmk_away> but I can live with the whitelist, its not worth arguing over
[03:09:52] <SWPadnos> we should have a filter that can pull the required names out of the makefile (or as an ls modules/*.{o,ko})
[03:09:57] <cradek> but setuid programs make the writer and the installer rightfully nervous
[03:09:58] <SWPadnos> during make
[03:10:36] <jmk_away> thinking about the directory that will contain the HAL module reminds me...
[03:10:56] <jmk_away> among the cruftiest code in halcmd is the code that finds the HAL module directory :-(
[03:11:07] <cradek> yeah
[03:11:16] <cradek> probably because of run-in-place
[03:11:28] <cradek> I had to add more similar crap to /etc/init.d/realtime
[03:11:29] <jmk_away> partly
[03:11:46] <jmk_away> but even installed, there are usually hooks that let the user install in non-standard places
[03:12:33] <cradek> I'm this close -><- to recommending we ditch run-in-place and use --prefix for separate versions like jepler says.
[03:13:01] <jmk_away> I will throw things at you
[03:13:01] <cradek> but I know people will scream bloody murder
[03:13:07] <cradek> and throw things at me
[03:13:30] <SWPadnos> ./configure --with-fscking-run-in-place=`pwd`
[03:13:56] <jmk_away> jepler mentioned the possiblility of "sudo make set-permissions" to set the setuid bits for run-in-place
[03:14:44] <jmk_away> perhaps "sudo make run-in-place" would be better? it would set setuid bits, as well as configure directories
[03:14:56] <jmk_away> basically an install that doesn't install, but does prep for running
[03:16:46] <jmk_away> what confuses me is that run-in-place should be easier, not harder, than run-installed
[03:17:01] <jmk_away> run-in-place always has the same directory layout, only the root changes
[03:17:01] <cradek> either is easy; supporting both is what's hard
[03:17:18] <jmk_away> run-installed can be overridden and re-arranged by the user
[03:18:53] <cradek> chris@buster2:/usr/src/emc2/src$ sudo make setuid
[03:18:53] <cradek> Password:
[03:18:53] <cradek> sudo chown root module_helper/emc_module_helper ../bin/halcmd
[03:18:54] <cradek> sudo chmod 4755 module_helper/emc_module_helper ../bin/halcmd
[03:21:04] <jepler> chmod 4750, so that it is not setuid for everyone, just users in my own primary group (maybe only me)?
[03:21:44] <jmk_away> seems reasonable
[03:22:03] <jmk_away> a run-in-place compile is probably in someone's home directory tree
[03:22:10] <jmk_away> only they are gonna run it in place
[03:22:13] <cradek> done
[03:23:12] <cradek> jepler: I like the splash screen changes
[03:23:17] <jmk_away> all of this depends on a good sudo setup, right?
[03:23:25] <cradek> make setuid? yes
[03:23:46] <cradek> even without it, it'll be obvious what the command is supposed to do
[03:23:54] <cradek> sudo isn't required for running emc anymore
[03:25:02] <jmk_away> src/Makefile: cvs update: move away `include/.cvsignore'; it is in the way
[03:25:03] <jmk_away> C include/.cvsignore
[03:25:05] <jmk_away> oops
[03:25:11] <jmk_away> cvs update: move away `include/.cvsignore'; it is in the way
[03:25:11] <jmk_away> C include/.cvsignore
[03:25:15] <jmk_away> oops again
[03:25:22] <jmk_away> cut/paste with KDE sucks
[03:25:35] <jmk_away> src/makefile: sudo chmod 4750 module_helper/emc_module_helper ../bin/halcmd
[03:26:18] <jmk_away> there is a sudo in the makefile, so if sudo doesn't work, you can't do the "make setuid"
[03:26:34] <jmk_away> why not drop the sudo, and let the user say "sudo make setuid"
[03:26:38] <cradek> true enough
[03:26:51] <jmk_away> or "su -c 'make setuid'"
[03:27:31] <jmk_away> or on a real multi-user system, call the sysadmin who logs in and does "make setuid" or "make install"
[03:27:51] <cradek> I feel bad for all the people wading through my one-line commit emails
[03:27:59] <jmk_away> why
[03:28:08] <SWPadnos> because
[03:28:10] <SWPadnos> there
[03:28:12] <SWPadnos> are
[03:28:12] <jmk_away> the cvs browser will let them see exactly what changes do what
[03:28:13] <SWPadnos> a
[03:28:15] <SWPadnos> lot
[03:28:15] <cradek> [wade wade wade]
[03:28:16] <SWPadnos> of
[03:28:18] <SWPadnos> them
[03:28:33] <cradek> jmk_away: I was only half serious
[03:28:41] <jmk_away> I know
[03:28:42] <SWPadnos> but even a bonehead can read them (trust me ;) )
[03:28:48] <cradek> haha
[03:28:54] <cradek> so has anyone tried run-in-place tonight?
[03:29:14] <cradek> I have a deb installed so I can't be sure it's working right
[03:29:16] <jmk_away> I will
[03:29:22] <jmk_away> cd src
[03:29:24] <jmk_away> oops
[03:29:25] <cradek> * cradek hides
[03:29:52] <jmk_away> you have a few mins, I'm doing a make clean/make
[03:30:17] <jmk_away> first I'll try without doing make setuid
[03:30:25] <jmk_away> (test the error handling ;-)
[03:30:49] <jepler> well I've made a bunch of changes to module_helper. should I check it in?
[03:30:50] <jmk_away> dammit jepler, now I have to cvs up again
[03:30:56] <cradek> jepler: sure
[03:31:01] <jmk_away> you just did didn't you?
[03:31:15] <jmk_away> oh, sorry, I saw the /tests commit
[03:33:17] <SWPadnos> so - is it safe to cvs up now? :)
[03:33:34] <cradek> I haven't seen the helper changes yet
[03:33:58] <SWPadnos> me either - the latest message I have is the cvsignore
[03:33:59] <jmk_away> why does emc_module_helper (executable) wind up in the src tree instead of emc2/bin?
[03:34:25] <cradek> good question
[03:34:43] <jepler> I'm waffling about whether to check in these changes, that's all
[03:35:03] <SWPadnos> do they help?
[03:35:11] <cradek> I waffled bigtime about this whole deal, but the team convinced me this morning that it's the way to progress, even if it's momentarily broken
[03:35:31] <cradek> so jump with both feet
[03:35:47] <SWPadnos> yes - before I start compiling
[03:35:55] <jmk_away> ditto
[03:36:16] <cradek> Starting emc...
[03:36:16] <cradek> Cannot find emc_module_helper or it is not installed properly (setuid root.)
[03:36:33] <cradek> run-in-place is broken with the default ./configure
[03:36:50] <jmk_away> you ran make setuid?
[03:37:17] <cradek> no, I forgot, but that doesn't help :-)
[03:38:39] <jepler> but for all that, my extension test doesn't seem to work. wth
[03:38:57] <jmk_away> wtf?! I keep getting these
[03:38:59] <jmk_away> cvs update: move away `rtlib/.cvsignore'; it is in the way
[03:39:00] <jmk_away> C rtlib/.cvsignore
[03:39:10] <jmk_away> I deleted my local .cvsignore files
[03:39:48] <jmk_away> got them for bin, include and rtlib
[03:40:25] <jmk_away> cd src
[03:40:29] <jmk_away> dammit
[03:41:04] <SWPadnos> gah - fonts need to clearly demark the lowercase 'L' and the numeral 'one'
[03:41:30] <SWPadnos> I'm looking at that last checkin, and I see "return target + 1"
[03:41:44] <jepler> SWPadnos: I can't control the font you use
[03:41:53] <SWPadnos> no, and it's a good thing, too
[03:42:04] <jmk_away> l1l1l1l1
[03:42:12] <SWPadnos> that I can see - you see
[03:43:05] <cradek> ok module_helper isn't going to install these modules since they're not in a whitelisted path
[03:43:20] <cradek> so for run-in-place, what do we do?
[03:43:29] <SWPadnos> funny - thanks (I think)
[03:44:02] <jmk_away> the whitelisted path is screwed anyway I think... what if the system uses a non-conventional path for modules?
[03:44:57] <jepler> for instance, /usr/local/realtime
[03:44:58] <jmk_away> perhaps the path should come from config.h?
[03:45:16] <cradek> well rtai really wants to use /usr/realtime
[03:45:20] <jmk_away> let configure figure out where they will be (in the installed and run-in-place cases)
[03:45:21] <cradek> others can use run-in-place
[03:46:23] <cradek> /lib/modules has been standard on every distribution since there were kernel modules
[03:46:47] <jepler> cradek: you're envisioning that .. run-in-place will use sudo, not module_helper ?
[03:47:02] <jmk_away> both should use module_helper
[03:47:24] <cradek> jepler: I was, yes, but maybe jmk is right
[03:47:36] <jepler> char *path_whitelist[] = { "/lib/modules", "/usr/realtime",
[03:47:37] <jepler> #ifdef EXTRA_WHITELIST_PATHS EXTRA_WHITELIST_PATHS,
[03:47:37] <jepler> #endif NULL
[03:47:40] <jepler> argh that's a terrible past
[03:47:41] <jepler> e
[03:48:13] <jepler> basically, arrange to -DEXTRA_WHITE_LIST_PATHS=\"...\" when you're configuring to run in place
[03:48:13] <cradek> I get the idea
[03:48:39] <jmk_away> "configuring to run in place"??
[03:48:58] <cradek> I'm getting more and more sick to my stomach about this
[03:49:07] <jmk_away> you mean run config and explicitly tell it you want to run in place, then make, run, then config again, make again, install?
[03:49:29] <jmk_away> eww
[03:49:55] <jepler> jmk_away: Always having another path whitelisted by module_helper (one that depends on where you ran configure) seems like a security problem
[03:50:02] <cradek> jmk_away: it's either that or you have your scripts guessing where things are
[03:50:08] <jmk_away> yeah, I know
[03:50:19] <jmk_away> its starting to make me sick too
[03:50:19] <cradek> jmk_away: just a minute ago you said we should have configure write these scripts properly
[03:50:37] <jmk_away> I was visualizing lines in config.h like:
[03:50:43] <jepler> it's my bedtime .. you guys figure this out
[03:51:19] <jmk_away> #define INSTALLED_MODULES_PATH "/lib/modules", "/usr/realtime"
[03:51:47] <jmk_away> #define RUNINPLACE_MODULES_PATH "/home/John/emcdev/emc2head/rtlib"
[03:52:17] <jmk_away> but I agree that you would want the second one disabled once installed
[03:52:48] <jmk_away> ok, I agree with you guys, run-in-place is becoming a royal pain
[03:53:04] <cradek> yeah. again I say we need to be careful to recognize when it's more trouble than it's worth.
[03:53:15] <jmk_away> loading modules directly from an individual user's directory is inherently insecure
[03:53:27] <jmk_away> but we MUST be able to have multiple versions on a box
[03:53:38] <jmk_away> and that means managing multiple sets of modules!
[03:53:52] <cradek> yeah.
[03:54:04] <jmk_away> you can't stick them all in usr/realtime or /lib/modules and expect it to pick the right ones
[03:54:43] <SWPadnos> any developer has to have the ability to install/remove modules, so as long as sudo 'whatever' works, it's OK
[03:54:49] <SWPadnos> (sudo emc, sudo module_helper, etc)
[03:55:06] <jmk_away> what mechanism is used by the kernel guys? you can certainly have two kernels on one box, and each kernel insmods the appropriate modules
[03:55:18] <cradek> /lib/modules/kernel-version/...
[03:55:36] <cradek> certainly they're not loaded from the source tree.
[03:55:42] <jmk_away> right
[03:56:01] <jmk_away> I was just asking, because their methods might (or might not) be applicable to us
[03:56:24] <SWPadnos> they're loaded from the development dir
[03:56:28] <jmk_away> for one thing, when we do an install, we should install into the kernel-version tree
[03:57:08] <cradek> yes, currently in my setup it's /usr/realtime-kernelversion/...
[03:57:19] <cradek> the realtime modules must be different for different kernel versions too.
[03:57:20] <jmk_away> if you have two kernels on a box and compile emc2 while running kernel 1, the modules will match kernel 1... if you are later running kernel 2, you don't want to use the kernel 1 compatible modules
[03:57:32] <cradek> jmk_away: yes, I actually got that right already.
[03:57:41] <jmk_away> ok, I didn't know
[03:58:08] <cradek> sorry, I didn't mean that to sound snippy
[03:58:17] <jmk_away> you didn't
[03:58:24] <cradek> but I am finding most of what I've done isn't 100% yet
[03:58:24] <jmk_away> anyway
[03:58:46] <jmk_away> this is brain twistin stuff, at least for me
[03:58:51] <cradek> but my f-ing debs work when I pick EMC on the applications menu
[03:59:02] <jmk_away> lol
[03:59:09] <cradek> that was my goal, and it works, but I steamrollered over everything else
[03:59:28] <jmk_away> we load three kinds of modules with module-helper
[03:59:36] <jmk_away> 1) ones we didn't compile: rtai stuff
[03:59:56] <jmk_away> 2) ones we did compile, but not HAL modules: rtapi.ko, hal_lib.ko
[04:00:00] <jmk_away> 3) hal modules
[04:00:15] <cradek> 4) kernel modules (adeos)
[04:00:26] <jmk_away> that is under #1
[04:00:37] <cradek> #1 is in /usr/realtime, #4 is in /lib/modules
[04:00:51] <SWPadnos> isa deos available as a module?
[04:00:52] <cradek> adeos is installed with the kernel, not rtai
[04:01:01] <jmk_away> we didn't compile either one tho ;-)
[04:01:02] <cradek> SWPadnos: yes
[04:01:03] <SWPadnos> I think it's compiled in, isn't it
[04:01:12] <cradek> SWPadnos: can be either
[04:01:17] <jmk_away> 1a: ones we didn't compile that are in /lib/modules: adeos
[04:01:25] <SWPadnos> ok - I haven't gotten anything recent to work anyway
[04:01:27] <jmk_away> 1b: ones we didn't compile that are in /usr/realtime
[04:01:35] <cradek> ok
[04:01:46] <cradek> I didn't want to argue a pedantic point, I thought it might be relevant.
[04:01:48] <jmk_away> anyway, 1 (a and b) is exactly the same for run-in-place and installed
[04:01:56] <cradek> ok right
[04:02:13] <jmk_away> 2 is a bit of a prick, they are "ordinary" kernel modules
[04:02:31] <jmk_away> 3 IMO should be in a subdir of their own, and halcmd should take modules only from that subdir
[04:03:04] <jmk_away> I don't want people to do "loadrt usb_camera_driver"
[04:03:36] <SWPadnos> is it terribly icky to recompile module_helper when make install is run, and have it use a different set of hardcoded paths?
[04:03:51] <SWPadnos> since you wouldn't awnt an installed version to be able to load from /home/me/...
[04:04:00] <cradek> SWPadnos: it would have to be recompiled...
[04:04:01] <SWPadnos> want
[04:04:05] <jmk_away> its icky... terribly depends on the alternatives, it might be less icky than other choices ;-/
[04:04:29] <SWPadnos> I think it's necessary, or the user directory is in the installed whitelist
[04:04:44] <SWPadnos> or the user can't use it as run-in-place
[04:05:01] <jmk_away> or you compile two versions, install one, keep the other in home/me/emc2/bin
[04:05:19] <cradek> can we pause for just a second
[04:05:22] <jmk_away> sure
[04:05:29] <SWPadnos> sure, but that's at least a 1 on the ickymeter
[04:05:29] <jmk_away> * jmk_away takes a leak
[04:05:30] <SWPadnos> ok
[04:05:35] <cradek> tonight, run-in-place is borken
[04:05:42] <cradek> most people who track cvs run-in-place
[04:05:53] <cradek> what should we do tonight? It's already 10pm here.
[04:06:04] <cradek> it could be as simple as an email to -dev
[04:06:46] <cradek> I wonder if I should have put this on a branch.
[04:07:26] <SWPadnos> I think run-in=place is more important at this point than installed
[04:07:44] <SWPadnos> install is more or less an experimental target for most of us, I think
[04:08:36] <cradek> that may be true for a couple days, but install is required for the release
[04:09:13] <SWPadnos> yes, and either both need to work then, or there needs to be a mail to the devlist telling people *before* run in place is broken
[04:11:02] <jmk_away> ideally run-in-place would be working when we go to sleep, even if installed isn't
[04:11:13] <SWPadnos> that was my thought
[04:11:23] <jmk_away> the fix can be ugly and temporary
[04:12:07] <jmk_away> for instance, temporarily whitelist <wherever>/emc2/rtlib as well as the other two paths
[04:12:23] <jmk_away> in the long run that is insecure, but tonight it makes things work (maybe)
[04:12:45] <cradek> only if you ./configure --the-right-way
[04:13:00] <SWPadnos> or disable path checking altogether, for now
[04:13:15] <jmk_away> disabling the path altogether might be better
[04:14:49] <cradek> let me see if that fixes it
[04:15:38] <SWPadnos> can you make it alpha blend those images, please :)
[04:15:51] <SWPadnos> I may want a logo on the wizard, after all
[04:17:08] <jmk_away> ok, tonights mission is apparently just to get it working, even if a bit insecure
[04:17:23] <jmk_away> later (soon) we think/talk it thru and refine
[04:17:57] <jmk_away> one of the things to think/talk about (related to the module path stuff) is how halcmd loadrt knows where the modules are
[04:18:47] <jmk_away> modules can vary based on kernel config (already handled in the installed case) and based on emc version (not handled at present, we use run-in-place and only allow one installed version)
[04:19:13] <jmk_away> is that a fair summary of the problem?
[04:20:02] <SWPadnos> would modprobe be better here? (for any installed version)
[04:20:23] <jmk_away> * jmk_away is scared of modprobe
[04:20:25] <SWPadnos> hmmm - except that it may silently load some other stuff you don't know about
[04:20:34] <jmk_away> (we fear that which we don't understand)
[04:20:54] <SWPadnos> well, it automatically loads from the correct /lib/modules-XXX dir
[04:20:56] <jmk_away> getting back to the three (or four) classes of modules
[04:21:01] <cradek> sometimes I feel like we've rewritten modprobe very, very clumsily
[04:21:06] <SWPadnos> yes
[04:21:15] <jmk_away> modprobe might be appropriate for 1a, 1b, and 2
[04:21:20] <jmk_away> 3 (hal modules) not so
[04:21:21] <SWPadnos> but with extra dirs, I think
[04:21:39] <jmk_away> hal modules should never be loaded except by HAL
[04:21:42] <SWPadnos> I think you can modprobe a module in the current dir, but I'm not sure how that works
[04:22:11] <cradek> ok now run-in-place works with ./configure --with-insmod="/usr/src/emc2/src/module_helper/emc_module_helper insert" --with-rmmod="/usr/src/emc2/src/module_helper/emc_module_helper remove"; make; sudo make setuid
[04:22:29] <cradek> replaced with your paths of course
[04:22:39] <jmk_away> oh gawd
[04:22:44] <SWPadnos> heh
[04:22:54] <SWPadnos> <splat>
[04:22:55] <jmk_away> iow, it doesn't work for anyone who was doing run-in-place yesterday
[04:23:11] <jmk_away> because they sure as heck won't be doing that
[04:23:34] <jmk_away> question: what if they don't do --with-insmod
[04:23:45] <jmk_away> does it use good old insmod?
[04:24:05] <cradek> no, I think scripts/realtime will fail then
[04:24:31] <cradek> what we really need is realtime.in -> configure -> realtime
[04:24:33] <jmk_away> if you don't pass configure the --with-insmod option what does it use?
[04:24:50] <cradek> doesn't matter because realtime is still broken (configure doesn't process it)
[04:25:15] <cradek> if we fix that, you could --with-insmod="sudo insmod" etc
[04:25:31] <jmk_away> realtime is now hard-coded to use the helper?
[04:25:38] <cradek> unfortunately
[04:25:46] <cradek> because it's not processed by configure at all
[04:25:55] <cradek> that's probably the right fix.
[04:26:03] <cradek> wonder if anybody but alex could figure out how to do it
[04:26:15] <jmk_away> not in the next couple of hours
[04:26:18] <cradek> I did successfully regenerate configure earlier
[04:26:30] <cradek> apparently I have the right versions of all that crap
[04:26:42] <jmk_away> I've done some fiddling with configure and configure.in
[04:27:14] <jmk_away> but I don't want to introduce realtime.in this late at night
[04:27:26] <jmk_away> it may be the right answer, but I'd rather think on it
[04:27:31] <cradek> I think it would actually be pretty easy
[04:27:41] <cradek> a couple lines of INSMOD="@INSMOD@"
[04:27:56] <jmk_away> hand on a sec
[04:28:07] <jmk_away> rtapi.conf has some of that stuff
[04:28:13] <jmk_away> it has MODULE_EXT
[04:28:26] <jmk_away> why couldn't it have INSMOD?
[04:29:03] <cradek> do those come from configure?
[04:29:12] <cradek> what generates rtapi.conf?
[04:29:23] <jmk_away> I'm trying to figure that out ;-/
[04:29:41] <cradek> hey I think I can do realtime.in in just a few minutes
[04:30:10] <SWPadnos> # Autogenerated by 'make' on Sun Jan 29 22:39:44 EST 2006
[04:30:57] <jmk_away> yes, the src/rtapi makefile
[04:31:47] <jmk_away> heh, it makes two of them
[04:31:55] <jmk_away> one for run-in-place, one for installe
[04:32:31] <SWPadnos> yep - one for install, one for normal make
[04:32:32] <cradek> config.status: creating ../scripts/emc
[04:32:32] <cradek> config.status: creating ../scripts/realtime
[04:32:36] <cradek> it's done
[04:32:45] <SWPadnos> I think that qualifies as icky ;)
[04:33:39] <jmk_away> heh, the good news is that as far as I can tell (grep) only the realtime script actually uses rtapi.conf
[04:34:13] <jmk_away> so if it is now directly generated by configure (from configure.in) probably all the stuff that used to be in rtapi.conf can be directly stuffed into realtime, and rtapi.conf can go away
[04:34:20] <jmk_away> (taking the icky with it)
[04:34:40] <jmk_away> s/from configure.in/from realtime.in/
[04:34:53] <jmk_away> why do I always see these things after I hit enter
[04:35:00] <cradek> I got a working run-in-place with ./configure --with-insmod="/usr/bin/sudo insmod" --with-rmmod="/usr/bin/sudo rmmod"; make
[04:35:11] <cradek> maybe I can make those the default, and we're done
[04:35:23] <cradek> and it'll be really clean since I removed the "guess and search" from realtime
[04:35:46] <jmk_away> why the --with-insmod at all?
[04:36:10] <cradek> so I can do --with-insmod="/usr/bin/emc_module_helper insert" when building the deb
[04:36:38] <SWPadnos> right - just change the default at some point
[04:36:39] <jmk_away> yeah, I understand that (don't like it, but thats another issue)
[04:36:52] <jmk_away> what I mean is make the default "insmod"
[04:36:54] <jmk_away> no sudo
[04:36:57] <cradek> this is only a matter of defaults then
[04:37:02] <cradek> the default IS insmod
[04:37:07] <jmk_away> for run-in-place, folks are used to typing
[04:37:08] <cradek> but that won't work unless you run sudo emc
[04:37:27] <jmk_away> "sudo emc" and "sudo realtime start" are just fine for run-in-place
[04:37:33] <jmk_away> that's what people were doing yesterday
[04:37:39] <cradek> no, they weren't
[04:37:46] <jmk_away> well, a week ago then
[04:37:47] <cradek> there were sudo droppings all over the scripts
[04:37:49] <SWPadnos> half the work on the scripts was to remove that, I'd like them to stay off
[04:38:03] <SWPadnos> (the sudo requirements)
[04:38:12] <jmk_away> ok, maybe I'm all mixed up
[04:38:31] <SWPadnos> you're so used to typing sudo -C, you probably never noticed
[04:38:39] <jmk_away> when I run here, I always do "sudo scripts/realtime start", "sudo bin/halcmd loadrt foo"
[04:38:55] <cradek> that hasn't been required for some time.
[04:38:56] <SWPadnos> I don't think I saw you type any command that didn't start with sudo - just to make sure ;)
[04:39:08] <jmk_away> not true
[04:39:24] <jmk_away> halcmd other than loadrt I don't type sudo
[04:39:42] <SWPadnos> I could swear I saw you run nano as su ;)
[04:39:51] <jmk_away> when?
[04:39:54] <SWPadnos> fest
[04:40:13] <jmk_away> maybe I was editing etc/some-config (getting networking to work or something)
[04:40:14] <SWPadnos> (kidding - but I did notice you typing su or sudo a lot more than I do)
[04:40:56] <jmk_away> I guess I have no problem with explicitly invoking the powers of root.
[04:41:21] <jmk_away> I don't particularly like having scripts full of sudo just so the user doesn't need to invoke the script with sudo
[04:41:38] <cradek> jmk_away: the idea was to try to reduce the number of things run as root
[04:41:42] <jmk_away> the diff is that one case is explicit, the other implicit
[04:41:53] <cradek> jmk_away: it was pretty half-baked.
[04:42:00] <SWPadnos> well - however it was yesterday (which I think doesn't require sudo) it should also be tomorrow
[04:42:20] <jmk_away> instead of running a massive script sudo (which also makes all the progs it invokes sudo) only use it where needed
[04:42:23] <jmk_away> and I agree with that
[04:43:37] <jmk_away> I guess I just want to take a big step backwards and look at the whole thing
[04:44:17] <jmk_away> I think the only thing that needs root power is module load/unload
[04:44:29] <jmk_away> the issue becomes what modules, from what directory
[04:45:58] <jmk_away> which leads to whitelists of files and paths... and leads to run-in-place vs installed
[04:46:58] <jmk_away> fsckit, I'm tired, and I still have a couple hours of lathe work to do
[04:47:10] <SWPadnos> for run-in-place, there's only one module dir for both rt and hal, right (emc2/rtlib)
[04:47:17] <SWPadnos> rtai and HAL
[04:47:22] <SWPadnos> sorry - RTAPI and HAL
[04:47:28] <jmk_away> heh
[04:47:30] <jmk_away> yes
[04:47:36] <jmk_away> (to the last one)
[04:47:39] <SWPadnos> right
[04:47:41] <SWPadnos> ;)
[04:47:42] <cradek> AHA
[04:47:44] <cradek> I think I got it
[04:47:59] <SWPadnos> oh sure, work while we talk - grea
[04:48:02] <SWPadnos> t
[04:51:56] <cradek> will one of you guys try it so I can know I got everything committed?
[04:53:28] <SWPadnos> it'll take a few minutes
[04:54:59] <cradek> yay I think it works
[04:55:17] <jmk_away> any special configure args?
[04:55:19] <cradek> ./configure picks "/usr/bin/sudo insmod" and "/usr/bin/sudo rmmod" by default
[04:55:27] <cradek> no, the defaults work for run-in-place
[04:56:06] <jmk_away> so that will work on systems with working sudo
[04:56:09] <cradek> well you could even install that way
[04:56:10] <jmk_away> good enough for now
[04:56:11] <cradek> yes
[04:56:16] <cradek> same as always, but clean
[04:56:21] <SWPadnos> I just did a clean checkout as a normal user, it'll be done compiling in a few minutes
[04:56:32] <jmk_away> compiling here too
[04:56:41] <cradek> SWPadnos: anoncvs is probably not updated yet
[04:56:45] <SWPadnos> you'll be done first, I can just about guarantee it
[04:56:50] <SWPadnos> I used my login
[04:56:55] <cradek> SWPadnos: ah ok
[04:57:03] <SWPadnos> "normal user" rather than root, which I was on that box
[04:57:09] <SWPadnos> (wouldn't be useful, I suspect)
[04:57:11] <cradek> gotcha
[04:57:31] <SWPadnos> presumably, this still works if you're actually root?
[04:57:35] <cradek> sure
[04:57:53] <cradek> you could specify --with-insmod=/sbin/insmod etc if you don't want to use sudo at all
[04:58:12] <cradek> then you'd have to run emc as root
[04:58:23] <SWPadnos> sudo shouldn't care if you're already root, right?
[04:58:30] <cradek> no, it doesn't care
[04:58:47] <cradek> I can't imagine why anyone would WANT to run emc as root though
[04:59:04] <SWPadnos> big machine go boom! - always fun
[04:59:16] <jmk_away> depending on how your sudo is set up, you might get the "enter your password" prompt in the middle of a script, right?
[04:59:21] <cradek> yes
[04:59:32] <cradek> including for shutting down emc
[04:59:38] <cradek> but that is not new
[04:59:50] <cradek> but it certainly does suck (and is why I started this mess)
[05:00:06] <jmk_away> one advantage of doing "sudo emc" gets it out of the way early
[05:00:08] <SWPadnos> what happens when that prompt goes to no terminal (such as running from an icon or menu)?
[05:00:16] <cradek> SWPadnos: you're screwed
[05:00:19] <jmk_away> then you are fcksed
[05:00:30] <SWPadnos> ok - that may not be good for release
[05:00:33] <cradek> SWPadnos: that's why bdi has sudo with no password, which is a terrible idea
[05:00:34] <jmk_away> thats why we need to return to this topic when it isn't almost midnight
[05:00:42] <SWPadnos> yep
[05:00:43] <cradek> SWPadnos: that's the whole idea behind emc_module_helper
[05:00:52] <cradek> no, guys, this is a solved problem now
[05:01:20] <jmk_away> run in place still uses sudo tho doesn't it?
[05:01:21] <SWPadnos> ok - right, module_helper is SUID root, so the actual load/unload whould work with no sudo
[05:01:41] <cradek> jmk_away: yes, but only for the necessary things (insmod/rmmod)
[05:02:18] <jmk_away> this will be truly solved with run-in-place also uses the helper
[05:02:46] <jmk_away> s/with/when/
[05:02:52] <SWPadnos> that shouldn't be an isse - anyone who can compiletheir own kernel modules should also be able to load them
[05:02:53] <cradek> that would mean making the helper weaker
[05:02:56] <SWPadnos> issue
[05:03:13] <cradek> I think sudo is fine for developers who use run-in-place.
[05:03:40] <jmk_away> but that brings back the "prompt in the middle of a script" issue
[05:03:57] <cradek> well people don't complain about that now
[05:04:02] <cradek> so they must all have a no-password sudo policy
[05:04:09] <SWPadnos> yep. it won't be as much of an issue once there are actual binary packages to distribute
[05:04:10] <cradek> because they're probably using bdi
[05:04:15] <jmk_away> yes
[05:04:39] <jmk_away> that will change if we move to the ubuntu distro (which I assume will have a stricter policy)
[05:04:43] <cradek> they could set up sudo to allow only insmod/rmmod without a password.
[05:05:03] <cradek> that would be much safer
[05:05:34] <cradek> the ubuntu default is to require a password for sudo always, but cache it for a while
[05:05:43] <jmk_away> right
[05:05:54] <cradek> it seems like a great way to handle sudo
[05:05:56] <jmk_away> I had a box like that (I think it was my BDI-TNG box)
[05:06:29] <jmk_away> works fine if you invoke sudo at the beginning of the script
[05:06:33] <cradek> but anyway, a developer can configure sudo however he wants. someone who installs the emc2 deb shouldn't have to mess with it (and won't now)
[05:06:41] <SWPadnos> ok - I just did a cvs co / ./configure / make, and scripts/emc can't insmod
[05:06:53] <cradek> SWPadnos: what did configure say for insmod/rmmod?
[05:06:55] <jmk_away> if you invoke it IN the script, for cleanup (machine was running for hours, cached password expired) you have a mess
[05:07:03] <SWPadnos> err - good question
[05:07:04] <cradek> jmk_away: yep
[05:07:22] <cradek> SWPadnos: check in config.log
[05:07:37] <cradek> jmk_away: again, that's the whole reason I made the module helper
[05:07:37] <SWPadnos> /usr/bin/sudo insmod
[05:07:49] <cradek> SWPadnos: what's the exact error you get?
[05:08:03] <SWPadnos> hmmm - I should re-login as me, rather than a root login, then su me
[05:08:22] <jmk_away> cradek: I know why you made it, and I concur... what bums me out is that you made it, but run-in-place can't use it
[05:08:36] <SWPadnos> steve@localhost:/Project/emc2-steve$ scripts/emc
[05:08:38] <SWPadnos> Machine configuration directory is '/Project/emc2-steve/configs/univstep/'
[05:08:40] <SWPadnos> Machine configuration file is 'univstep.ini'
[05:08:41] <SWPadnos> Starting emc...
[05:08:43] <SWPadnos> sudo: insmod: command not found
[05:08:44] <SWPadnos> sudo: insmod: command not found
[05:08:45] <cradek> jmk_away: maybe it can, but that's phase 2
[05:08:46] <SWPadnos> sudo: insmod: command not found
[05:08:47] <SWPadnos> sudo: insmod: command not found
[05:08:49] <SWPadnos> sudo: insmod: command not found
[05:08:50] <SWPadnos> sudo: insmod: command not found
[05:08:52] <SWPadnos> sudo: insmod: command not found
[05:08:53] <SWPadnos> sudo: insmod: command not found
[05:08:54] <cradek> ok ok ok
[05:08:55] <SWPadnos> sudo: insmod: command not found
[05:08:57] <SWPadnos> ERROR: Could not load 'rtapi'
[05:08:58] <SWPadnos> ERROR: Could not load 'hal_lib'
[05:09:00] <SWPadnos> Realtime system did not load
[05:09:01] <SWPadnos> Shutting down and cleaning up EMC...
[05:09:02] <SWPadnos> Cleanup done
[05:09:04] <SWPadnos> steve@localhost:/Project/emc2-steve$
[05:09:09] <jmk_away> got the same as swp when I tried "realtime start"
[05:09:18] <cradek> you both bdi?
[05:09:22] <SWPadnos> yes
[05:09:25] <cradek> * cradek grumbles under his breath
[05:09:26] <SWPadnos> 4.30
[05:09:28] <SWPadnos> heh
[05:09:30] <jmk_away> I know why
[05:09:32] <cradek> where's your insmod?
[05:09:39] <jmk_away> /sbin
[05:09:51] <SWPadnos> yep
[05:09:52] <jmk_away> sudo insmod on the command line doesn't work if you are a regular user
[05:10:05] <cradek> it sure as hell does for me
[05:10:09] <cradek> I'll hardcode that path
[05:10:12] <jmk_away> sudo /sbin/insmod does
[05:10:53] <SWPadnos> /sbin isn't in the normal user's path
[05:11:05] <SWPadnos> s/the/a/
[05:11:35] <cradek> committed
[05:13:37] <cradek> when's the part of the weekend where I get to relax?
[05:13:45] <cradek> at least I get paid big bucks for all of this work and heartache
[05:14:08] <SWPadnos> when irc isn't accessible
[05:14:36] <cradek> does it work on bdi now?
[05:14:41] <SWPadnos> steve@localhost:/Project/emc2-steve$ scripts/emc
[05:14:43] <SWPadnos> bash: scripts/emc: Permission denied
[05:14:44] <SWPadnos> steve@localhost:/Project/emc2-steve$
[05:14:49] <cradek> you didn't make
[05:14:49] <SWPadnos> do I need to make as well?
[05:14:53] <SWPadnos> nope - OK
[05:15:03] <cradek> * cradek cringes at the thought of testing rtlinux
[05:15:24] <SWPadnos> heh
[05:15:58] <cradek> that is not a priority right now...
[05:16:06] <jmk_away> heh, realtime isn't executable now
[05:16:12] <jmk_away> (because it was made from realtime.in)
[05:16:14] <SWPadnos> ok - all better
[05:16:25] <SWPadnos> nope - hold on
[05:16:46] <SWPadnos> right - same as jmk
[05:16:58] <cradek> jmk_away: $RTAPICONF should come from configure too now
[05:17:06] <jmk_away> I did chmod a+x scripts/realtime and now it works
[05:17:25] <cradek> I must have missed a file in my commit; I fixed that
[05:17:35] <SWPadnos> it's executable on my machine
[05:17:37] <jmk_away> do I need to make to do the chmod?
[05:17:44] <cradek> yes
[05:17:50] <jmk_away> ok, thats it
[05:17:57] <cradek> ok I did check it in then
[05:17:58] <jmk_away> I was lazy, didn't want to make everything
[05:18:02] <SWPadnos> but it still doesn't work
[05:18:06] <cradek> what's wrong now?
[05:18:23] <SWPadnos> steve@localhost:/Project/emc2-steve$ scripts/emc
[05:18:25] <SWPadnos> Machine configuration directory is '/Project/emc2-steve/configs/univstep/'
[05:18:26] <SWPadnos> Machine configuration file is 'univstep.ini'
[05:18:28] <SWPadnos> Starting emc...
[05:18:30] <SWPadnos> HAL:4: ERROR: Must be root to load realtime modules
[05:18:31] <SWPadnos> HAL:4: ERROR: child did not exit normally
[05:18:33] <SWPadnos> HAL config file /Project/emc2-steve/configs/univstep//univstep_load.hal failed.
[05:18:34] <SWPadnos> Shutting down and cleaning up EMC...
[05:18:36] <SWPadnos> Cleanup done
[05:18:37] <SWPadnos> steve@localhost:/Project/emc2-steve$
[05:18:40] <cradek> you forgot make setuid
[05:18:44] <cradek> sudo make setuid
[05:18:45] <SWPadnos> it gets through setupconfig, but then dies
[05:18:47] <SWPadnos> ok - right
[05:19:14] <SWPadnos> ok - that's better
[05:19:32] <SWPadnos> (but jeplers popimage changes don't work on this remote X setup)
[05:19:38] <SWPadnos> it's not centered
[05:19:54] <cradek> * cradek plays a very small violin
[05:20:08] <SWPadnos> heh - not a problem for this evening
[05:20:28] <jmk_away> I haven't tried emc itself yet
[05:20:32] <jmk_away> realtime start now works
[05:20:33] <SWPadnos> I'm not sure that Cygwin correctly returns whatever he was using anyway, so it may be my own problem
[05:20:41] <jmk_away> halcmd loadrt doesn't
[05:20:41] <SWPadnos> emc runs - I have it up and running
[05:20:55] <SWPadnos> it doesn't use module_helper yet ;)
[05:20:56] <cradek> jmk_away: look up 10 lines (run sudo make setuid)
[05:20:58] <jmk_away> HAL:0: ERROR: Cannot locate realtime modules directory
[05:21:03] <jmk_away> did that
[05:21:17] <jmk_away> this seems like the bundle-o-cruft directory finding code
[05:21:24] <cradek> I'm not familiar with that error
[05:21:28] <jmk_away> I bet the main emc script sets the env var
[05:21:40] <jmk_away> but naked halcmd doesn't
[05:21:49] <cradek> I don't follow
[05:22:00] <cradek> I did not change anything about how halcmd was run
[05:22:11] <jmk_away> maybe it was busted earlier
[05:22:18] <jmk_away> (but I thought it worked)
[05:24:19] <cradek> so you can't run emc?
[05:24:24] <cradek> or is this some other thing?
[05:24:25] <jmk_away> I didn't try emc
[05:24:31] <jmk_away> I suspect it will be ok
[05:24:50] <cradek> please try it; that's what I want to work by bedtime.
[05:24:51] <SWPadnos> it's fine
[05:25:05] <SWPadnos> and it does export HAL_RTMOD_DIR
[05:27:09] <jmk_away> cd ..
[05:27:23] <SWPadnos> -EWRONGWINDOW
[05:27:44] <jmk_away> it works!!
[05:28:10] <jmk_away> we should add a note about "make setuid" to the boxed comment at the end of configure
[05:28:23] <cradek> I was just doing that
[05:28:29] <SWPadnos> yeah, and put the flashing back
[05:28:31] <jmk_away> great minds and all that rot
[05:30:31] <jmk_away> * jmk_away fires up the lathe
[05:30:42] <cradek> goodnight all
[05:30:48] <cradek> thanks for helping me unfuck everything
[05:30:49] <SWPadnos> noght
[05:30:52] <SWPadnos> night
[05:31:23] <jmk_away> thanks for all your work (fscking and unfscking, the net result is major progress)
[05:31:33] <cradek> you're welcome, and I agree
[05:31:38] <cradek> this is great now
[05:33:43] <SWPadnos> heh
[05:33:55] <SWPadnos> yep - I'll chime in with a thanks as well
[05:34:16] <SWPadnos> this make and above-make level stuff is a little mystical to me
[05:34:37] <cradek> only a little? you're the expert then
[05:34:59] <SWPadnos> heh "indistinguishable from magic" and all that