Menu
▾
▴
trap-devel — Developers Mailing List
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|---|
|
From: Manan D. <ma...@at...> - 2003-12-11 12:48:33
|
Golpa, I kinda like the idea of 1, but how hard would it be to code this up? I haven't looked at SSL much, but it cetainly seems easier of the two. Then again, since you are going to be writing everything anyways, what do I care? go for it! heh.. Manan. On Wed, 3 Dec 2003, Navid Golpayegani wrote: > Hey, > I know you have finals/projects due so there is no rush to this. It can > wait till after semester is over. > > Anyways, the original way I wrote up the encryption/authentication scheme > was just extremely bad so I erased it all. I want to rewrite it soon so we > can get the server done. Here are two solutions I can think of: > 1) Priv/Pub Key. > The server has one Sec/Pub key and two pub keys for each client. > Each client has two Secret/Publick key pairs + pub key of server > a)client connects it sends its identity > b)Server replies with random number > c)Client sends signature with secret key 1 of that number + new random > number + a session key (symmetric cipher) encrypted with secret key 2 > d)Server verifies signature and signs the new random number with it's > secret key and sends it to client > e)Client verifies the signature. > f)If both verifications are good they continue talking in encrypted > format with the session key sent by client in step c > > 2) SSL > I haven't looked at this in detail yet. But for this I doubt we would > have to worry about any protocol details. I think all we need is to > create a few pub/priv keys and SSL does the rest for us. We might need > to have signed certificates though. > > What ya guys think? > > Navid > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Trap-devel mailing list > Tra...@li... > https://lists.sourceforge.net/lists/listinfo/trap-devel > |
|
From: Navid G. <go...@at...> - 2003-12-03 18:44:11
|
Hey,
I know you have finals/projects due so there is no rush to this. It can
wait till after semester is over.
Anyways, the original way I wrote up the encryption/authentication scheme
was just extremely bad so I erased it all. I want to rewrite it soon so we
can get the server done. Here are two solutions I can think of:
1) Priv/Pub Key.
The server has one Sec/Pub key and two pub keys for each client.
Each client has two Secret/Publick key pairs + pub key of server
a)client connects it sends its identity
b)Server replies with random number
c)Client sends signature with secret key 1 of that number + new random
number + a session key (symmetric cipher) encrypted with secret key 2
d)Server verifies signature and signs the new random number with it's
secret key and sends it to client
e)Client verifies the signature.
f)If both verifications are good they continue talking in encrypted
format with the session key sent by client in step c
2) SSL
I haven't looked at this in detail yet. But for this I doubt we would
have to worry about any protocol details. I think all we need is to
create a few pub/priv keys and SSL does the rest for us. We might need
to have signed certificates though.
What ya guys think?
Navid
|
|
From: Navid G. <go...@at...> - 2003-05-11 06:39:23
|
Done. Called global.h/cpp. Any class that's in server directory should use
this. Since the global vars for server and client aren't the same we can't
use the same class for both. So shared class still needs to use the old
style unless you guys have a better idea.
Anyways for now this means plugindescriptor, computerlist, jobs need to be
modified to use global.h. How you deal with it internally is up to you.
Navid
On Sun, 11 May 2003, James Crawford wrote:
> That sounds like a good idea to me. Go ahead.
>
> James
>
> On Sat, 10 May 2003, Navid Golpayegani wrote:
>
> > Well we're at 4 global classes. It's getting a bit too much to handle
> > seperatly. Anybody have any objections if I create a class around it that
> > doesn't do much but just keep them handy in one place? Something as simple
> > as this:
> > class Global{
> > public:
> > Configuration *conf;
> > Log *log;
> > etc...
> > };
> >
> > Maybe even include some of the more general functions like reload() that
> > way one call of reload forces all the global classes to reload. If I don't
> > get any objections by tomorrow I'm implementing it.
> >
> > Navid
> >
> >
> > -------------------------------------------------------
> > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> > The only event dedicated to issues related to Linux enterprise solutions
> > www.enterpriselinuxforum.com
> >
> > _______________________________________________
> > Trap-devel mailing list
> > Tra...@li...
> > https://lists.sourceforge.net/lists/listinfo/trap-devel
> >
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Trap-devel mailing list
> Tra...@li...
> https://lists.sourceforge.net/lists/listinfo/trap-devel
>
|
|
From: James C. <dr...@th...> - 2003-05-11 05:16:33
|
That sounds like a good idea to me. Go ahead.
James
On Sat, 10 May 2003, Navid Golpayegani wrote:
> Well we're at 4 global classes. It's getting a bit too much to handle
> seperatly. Anybody have any objections if I create a class around it that
> doesn't do much but just keep them handy in one place? Something as simple
> as this:
> class Global{
> public:
> Configuration *conf;
> Log *log;
> etc...
> };
>
> Maybe even include some of the more general functions like reload() that
> way one call of reload forces all the global classes to reload. If I don't
> get any objections by tomorrow I'm implementing it.
>
> Navid
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Trap-devel mailing list
> Tra...@li...
> https://lists.sourceforge.net/lists/listinfo/trap-devel
>
|
|
From: Navid G. <go...@at...> - 2003-05-11 01:17:30
|
Well we're at 4 global classes. It's getting a bit too much to handle
seperatly. Anybody have any objections if I create a class around it that
doesn't do much but just keep them handy in one place? Something as simple
as this:
class Global{
public:
Configuration *conf;
Log *log;
etc...
};
Maybe even include some of the more general functions like reload() that
way one call of reload forces all the global classes to reload. If I don't
get any objections by tomorrow I'm implementing it.
Navid
|
|
From: Navid G. <go...@at...> - 2003-05-02 19:24:54
|
Looks good. Later on we might make the config file a little user friendly (like users can put as many white spaces as they want, order doesn't matter, etc...). One thing that I think you need to change is the listallPlugins() function. Currently it's returning an array whose size I can't figure out. Easiest thing I think is to just change it to return a vector or a list instead of a string *. Both of those I know the number of strings are stored in it. Navid On Fri, 2 May 2003, Manan Dalal wrote: > Aight, just committed pluginDescriptor class. I wasn't able to compile it > as Golpa knows, cuz James' configure shit doesn't work. But I have taken > bits and pieces of the code out and compiled separately (mostly the main > parsing portion), and that has worked. > I've also attached two sample descriptor files, one is bad, the other is > partially bad. I tried to make the file as freely written as possible. Let > me know if you think this is not a "good" format, and we can argue. > Also, my program will only read files with .dsc extension in a plugin > directory. It will also ignore . and .. dirs. > > Let me know what else I can do to help. I want to see this program > running, should be very cool. > > On Thu, 17 Apr 2003 tra...@li... wrote: > > > Way we can figure out the paring later. While we figure something out you > > can write the parser to read the descriptor file. A few things: > > 1) Make it thread safe. That means functions should lock a mutex and > > unlock. Look at shared/log.cpp|.h for example. > > 2) Your constructors should accept a Log class and a Configuration class. > > Both are pointers. The log class you should use to write log > > messages. The configuration file you'll use to figure out where the > > directory is that descriptor files are stored. You can assume > > pluginDescriptionDir is the parameter used in the configuration file. > > 3) Exceptions. Make sure you catch them all. new and delete will throw > > them so make sure to catch em and act accordingly. Also you can throw > > exceptions. Serious (unexpected) errors should throw exceptions. For > > example getParameter() from configuration class shouldn't throw an > > exception when you ask for a parameter that doesn't exist. But it > > should throw an exception if it tries to allocate memory to pass the > > result back to the caller and fails. > > 4) Reentrant functions. Make sure any functions you use are either > > reentrant or thread safe. > > 5) This is a server only class so it should go into the server directory. > > Oh and if/when you commit make sure to write a comment when > > cvs asks you for one. Otherwise the sourceforge cvs locks and never > > unlocks it until sourceforge ppl fix it. > > 6) Use the string class to store strings and use stl to do vectors/linked > > lists/whatever. It's faster to code and probably will avoid some easily > > missed buffer overflows. > > > > Make sure to leave room for parsing that one line of the descriptor once > > we decide what to do with it. > > > > James did I forget anything he needs his class to do? > > > > Navid > > > > Manan > |
|
From: Manan D. <ma...@at...> - 2003-05-02 18:24:24
|
Aight, just committed pluginDescriptor class. I wasn't able to compile it as Golpa knows, cuz James' configure shit doesn't work. But I have taken bits and pieces of the code out and compiled separately (mostly the main parsing portion), and that has worked. I've also attached two sample descriptor files, one is bad, the other is partially bad. I tried to make the file as freely written as possible. Let me know if you think this is not a "good" format, and we can argue. Also, my program will only read files with .dsc extension in a plugin directory. It will also ignore . and .. dirs. Let me know what else I can do to help. I want to see this program running, should be very cool. On Thu, 17 Apr 2003 tra...@li... wrote: > Way we can figure out the paring later. While we figure something out you > can write the parser to read the descriptor file. A few things: > 1) Make it thread safe. That means functions should lock a mutex and > unlock. Look at shared/log.cpp|.h for example. > 2) Your constructors should accept a Log class and a Configuration class. > Both are pointers. The log class you should use to write log > messages. The configuration file you'll use to figure out where the > directory is that descriptor files are stored. You can assume > pluginDescriptionDir is the parameter used in the configuration file. > 3) Exceptions. Make sure you catch them all. new and delete will throw > them so make sure to catch em and act accordingly. Also you can throw > exceptions. Serious (unexpected) errors should throw exceptions. For > example getParameter() from configuration class shouldn't throw an > exception when you ask for a parameter that doesn't exist. But it > should throw an exception if it tries to allocate memory to pass the > result back to the caller and fails. > 4) Reentrant functions. Make sure any functions you use are either > reentrant or thread safe. > 5) This is a server only class so it should go into the server directory. > Oh and if/when you commit make sure to write a comment when > cvs asks you for one. Otherwise the sourceforge cvs locks and never > unlocks it until sourceforge ppl fix it. > 6) Use the string class to store strings and use stl to do vectors/linked > lists/whatever. It's faster to code and probably will avoid some easily > missed buffer overflows. > > Make sure to leave room for parsing that one line of the descriptor once > we decide what to do with it. > > James did I forget anything he needs his class to do? > > Navid > Manan |
|
From: Navid G. <go...@at...> - 2003-04-26 19:29:20
|
James, I was wondering if there's an easy way to modify your computerlist class to add the following feature. Currently I can get a list of groups and a list of computers. But from that info I don't know what computer is in what group. When the admin wants to add commands to the queue he'll probably want to know what computers are part of a group. So we somehow have to send that info to the client program. Navid |
|
From: <tra...@li...> - 2003-04-18 02:33:21
|
Way we can figure out the paring later. While we figure something out you can write the parser to read the descriptor file. A few things: 1) Make it thread safe. That means functions should lock a mutex and unlock. Look at shared/log.cpp|.h for example. 2) Your constructors should accept a Log class and a Configuration class. Both are pointers. The log class you should use to write log messages. The configuration file you'll use to figure out where the directory is that descriptor files are stored. You can assume pluginDescriptionDir is the parameter used in the configuration file. 3) Exceptions. Make sure you catch them all. new and delete will throw them so make sure to catch em and act accordingly. Also you can throw exceptions. Serious (unexpected) errors should throw exceptions. For example getParameter() from configuration class shouldn't throw an exception when you ask for a parameter that doesn't exist. But it should throw an exception if it tries to allocate memory to pass the result back to the caller and fails. 4) Reentrant functions. Make sure any functions you use are either reentrant or thread safe. 5) This is a server only class so it should go into the server directory. Oh and if/when you commit make sure to write a comment when cvs asks you for one. Otherwise the sourceforge cvs locks and never unlocks it until sourceforge ppl fix it. 6) Use the string class to store strings and use stl to do vectors/linked lists/whatever. It's faster to code and probably will avoid some easily missed buffer overflows. Make sure to leave room for parsing that one line of the descriptor once we decide what to do with it. James did I forget anything he needs his class to do? Navid On Thu, 17 Apr 2003, James Crawford wrote: > On Thu, 17 Apr 2003, Manan Dalal wrote: > > > > Even though first one is invalid the server should just send that when the > > > admin program asks for it. The admin program will decide if it can > > > understand what it was given. > > > > But don't you think by the time the admin program decides if it can > > understand that it's too late to recover? It will just caugh up and say, > > "Sorry but I'm a big dufus and can't read this piece of shit you've just > > given me." Instead if we let my class do some kind of basic formatting, > > then we would avoid entries like funcargs=lalalala. Also, if plugin > > descriptions are going to be read in when server starts, then it may be > > helpful to let the writer of the plugin know that his pluging descriptor > > file is fucked rather than let someone try it and then figure out that he > > was just lalalala when he wrote that shizel ma nizel... > > I have to say that I agree with this. I'm of the opinion that all input > should be checked, immediately. If the server reads in something, check > it. No sense in passing on bad information if you can stop it immediately. > > That's just my opinion though. > > Even with jobs and such, the server should check that a job that an admin > adds is syntactically correct and that whatever plugin it's going to use > supports whatever it is the command is trying to do. It may add some > slight overhead, but I think it would catch a lot of problems that way. > > James > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Trap-devel mailing list > Tra...@li... > https://lists.sourceforge.net/lists/listinfo/trap-devel > |
|
From: Navid G. <go...@at...> - 2003-04-18 00:08:48
|
On Thu, 17 Apr 2003, James Crawford wrote: > On Thu, 17 Apr 2003, Manan Dalal wrote: > > > > Even though first one is invalid the server should just send that when the > > > admin program asks for it. The admin program will decide if it can > > > understand what it was given. > > > > But don't you think by the time the admin program decides if it can > > understand that it's too late to recover? It will just caugh up and say, > > "Sorry but I'm a big dufus and can't read this piece of shit you've just > > given me." Instead if we let my class do some kind of basic formatting, > > then we would avoid entries like funcargs=lalalala. Also, if plugin > > descriptions are going to be read in when server starts, then it may be > > helpful to let the writer of the plugin know that his pluging descriptor > > file is fucked rather than let someone try it and then figure out that he > > was just lalalala when he wrote that shizel ma nizel... > > I have to say that I agree with this. I'm of the opinion that all input > should be checked, immediately. If the server reads in something, check > it. No sense in passing on bad information if you can stop it immediately. I agree the server shouldn't store bad information. But this isn't something the server stored. It was created by the plugin programmer. Either way I just think adding another parser to the server part makes the server unecessarily complicated. This could then create potential exploits that a hax0r can use to gain root access (remember the server is running as root since it can't fully drop privs). > > That's just my opinion though. > > Even with jobs and such, the server should check that a job that an admin > adds is syntactically correct and that whatever plugin it's going to use > supports whatever it is the command is trying to do. It may add some > slight overhead, but I think it would catch a lot of problems that way. > The overhead might not be that slight. Imagine that you have a 50 or so plugins each with 10-15 functions.That's 500-750 arguments it has to parse. Some of which can be quite complicated. The parsing could potentially get to the point that it overloads the server with all the background connections going on at the same time. My main concern however is still the security. By having a fairly complicated parser in the server we might be risking possible exploits by incorrectly creating descriptor files. If however the incorrectly created descriptor is parsed by the admin program the worse that would happen is they gain access to the account running the admin program. But at the same time there's somebody sitting there noticing the crash. > James > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Trap-devel mailing list > Tra...@li... > https://lists.sourceforge.net/lists/listinfo/trap-devel > |
|
From: James C. <dr...@th...> - 2003-04-17 23:36:19
|
On Thu, 17 Apr 2003, Manan Dalal wrote: > > Even though first one is invalid the server should just send that when the > > admin program asks for it. The admin program will decide if it can > > understand what it was given. > > But don't you think by the time the admin program decides if it can > understand that it's too late to recover? It will just caugh up and say, > "Sorry but I'm a big dufus and can't read this piece of shit you've just > given me." Instead if we let my class do some kind of basic formatting, > then we would avoid entries like funcargs=lalalala. Also, if plugin > descriptions are going to be read in when server starts, then it may be > helpful to let the writer of the plugin know that his pluging descriptor > file is fucked rather than let someone try it and then figure out that he > was just lalalala when he wrote that shizel ma nizel... I have to say that I agree with this. I'm of the opinion that all input should be checked, immediately. If the server reads in something, check it. No sense in passing on bad information if you can stop it immediately. That's just my opinion though. Even with jobs and such, the server should check that a job that an admin adds is syntactically correct and that whatever plugin it's going to use supports whatever it is the command is trying to do. It may add some slight overhead, but I think it would catch a lot of problems that way. James |
|
From: Manan D. <ma...@at...> - 2003-04-17 22:58:41
|
> Sounds fine to me except for one thing. Don't try to parse what's given as > arguments for the function. The server doesn't really need to know what > all of that stuff means. It just needs to send it off to the admin > program. So your program doesn't care if it is: > funcargs=lalalala > or > funcargs=<text><text><text> > > Even though first one is invalid the server should just send that when the > admin program asks for it. The admin program will decide if it can > understand what it was given. But don't you think by the time the admin program decides if it can understand that it's too late to recover? It will just caugh up and say, "Sorry but I'm a big dufus and can't read this piece of shit you've just given me." Instead if we let my class do some kind of basic formatting, then we would avoid entries like funcargs=lalalala. Also, if plugin descriptions are going to be read in when server starts, then it may be helpful to let the writer of the plugin know that his pluging descriptor file is fucked rather than let someone try it and then figure out that he was just lalalala when he wrote that shizel ma nizel... > > Navid > Manan. |
|
From: Navid G. <go...@at...> - 2003-04-17 22:49:28
|
Sounds fine to me except for one thing. Don't try to parse what's given as arguments for the function. The server doesn't really need to know what all of that stuff means. It just needs to send it off to the admin program. So your program doesn't care if it is: funcargs=lalalala or funcargs=<text><text><text> Even though first one is invalid the server should just send that when the admin program asks for it. The admin program will decide if it can understand what it was given. Navid On Thu, 17 Apr 2003, Manan Dalal wrote: > Here it is...let me know what you guys think... > > Manan. > > On Wed, 16 Apr 2003, Navid Golpayegani wrote: > > > On Wed, 16 Apr 2003, James Crawford wrote: > > > > > I know the "above junk" is just an example, and so might not actually > > > represent the actual implementation, but when you say: > > > > > > > rm script=<text Path> > > > > > > Are you saying the command would be implemented as a script, or what? I'm > > > just curious how you plan to implement commands in the plugins. The > > > descriptor file you specified seems fine to me, and I agree... no XML. > > > > > No, that was just something I came up with in 5 seconds just as an > > example. The format of what to call it is all manan's choice. What I meant > > with that line is that the interactive program that the sysadmin uses to > > add commands to the queue needs to somehow know what to ask the sysadmin. > > For the above example the rm program needs to know the path to the file to > > erase. That line would tell the interactive program that it should ask for > > some text to be entered and that the label of the text should be "Path". > > The exact format of it we can make up later once we write the interactive > > program but as far as the program that manan writes now it doesn't matter. > > It would store that thing as a string and send it to the interactive > > program whenever it's required. > > > > The plugin itself will still be written in C/C++ and of course doesn't > > just do some system() call to do the actual rm. > > > > Navid > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Trap-devel mailing list > > Tra...@li... > > https://lists.sourceforge.net/lists/listinfo/trap-devel > > |
|
From: Navid G. <go...@at...> - 2003-04-17 22:44:26
|
I think it's fine if it's specialized. I don't see why we would use the database for anything else. I don't know much about structure vs. tables so whatever is easier for you to code is fine. On Thu, 17 Apr 2003, James Crawford wrote: > Alright a question for you guys... probably mainly Navid, but if Manan has > some ideas, I'd be happy to hear them. > > Do you foresee any place where we'd use SQLite database access other than > with regards to the jobs? I'm trying to decide just how abstract I want > this SQL class to be. If it's just going to be used for storing and > retrieving jobs, then I can just make the class specific to the table > format that will be used in the jobs database. Otherwise, to make it more > generally accessible would require quite a bit more coding. > > Also, with respect to the jobs database, I still haven't decided a good > database layout (tables, structure). Thoughts on this as well? > > James > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Trap-devel mailing list > Tra...@li... > https://lists.sourceforge.net/lists/listinfo/trap-devel > |
|
From: James C. <dr...@th...> - 2003-04-17 22:28:30
|
Alright a question for you guys... probably mainly Navid, but if Manan has some ideas, I'd be happy to hear them. Do you foresee any place where we'd use SQLite database access other than with regards to the jobs? I'm trying to decide just how abstract I want this SQL class to be. If it's just going to be used for storing and retrieving jobs, then I can just make the class specific to the table format that will be used in the jobs database. Otherwise, to make it more generally accessible would require quite a bit more coding. Also, with respect to the jobs database, I still haven't decided a good database layout (tables, structure). Thoughts on this as well? James |
|
From: Manan D. <ma...@at...> - 2003-04-17 21:05:49
|
Here it is...let me know what you guys think... Manan. On Wed, 16 Apr 2003, Navid Golpayegani wrote: > On Wed, 16 Apr 2003, James Crawford wrote: > > > I know the "above junk" is just an example, and so might not actually > > represent the actual implementation, but when you say: > > > > > rm script=<text Path> > > > > Are you saying the command would be implemented as a script, or what? I'm > > just curious how you plan to implement commands in the plugins. The > > descriptor file you specified seems fine to me, and I agree... no XML. > > > No, that was just something I came up with in 5 seconds just as an > example. The format of what to call it is all manan's choice. What I meant > with that line is that the interactive program that the sysadmin uses to > add commands to the queue needs to somehow know what to ask the sysadmin. > For the above example the rm program needs to know the path to the file to > erase. That line would tell the interactive program that it should ask for > some text to be entered and that the label of the text should be "Path". > The exact format of it we can make up later once we write the interactive > program but as far as the program that manan writes now it doesn't matter. > It would store that thing as a string and send it to the interactive > program whenever it's required. > > The plugin itself will still be written in C/C++ and of course doesn't > just do some system() call to do the actual rm. > > Navid > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Trap-devel mailing list > Tra...@li... > https://lists.sourceforge.net/lists/listinfo/trap-devel > |
|
From: Navid G. <go...@at...> - 2003-04-16 13:24:48
|
On Wed, 16 Apr 2003, James Crawford wrote: > I know the "above junk" is just an example, and so might not actually > represent the actual implementation, but when you say: > > > rm script=<text Path> > > Are you saying the command would be implemented as a script, or what? I'm > just curious how you plan to implement commands in the plugins. The > descriptor file you specified seems fine to me, and I agree... no XML. > No, that was just something I came up with in 5 seconds just as an example. The format of what to call it is all manan's choice. What I meant with that line is that the interactive program that the sysadmin uses to add commands to the queue needs to somehow know what to ask the sysadmin. For the above example the rm program needs to know the path to the file to erase. That line would tell the interactive program that it should ask for some text to be entered and that the label of the text should be "Path". The exact format of it we can make up later once we write the interactive program but as far as the program that manan writes now it doesn't matter. It would store that thing as a string and send it to the interactive program whenever it's required. The plugin itself will still be written in C/C++ and of course doesn't just do some system() call to do the actual rm. Navid |
|
From: James C. <dr...@th...> - 2003-04-16 13:06:28
|
On Tue, 15 Apr 2003, Navid Golpayegani wrote: > Here's an example for a unix plugin that has the ability to erase and > symlink files: > > Description=Plugin that performs various unix commands. > Functions=rm,ln > rm description=Erases files or directories > ln description=Creates a symlink to an already existing file/directory > rm script=<text Path> > ln script=<text Source><text Destination><bool Symbolic> > > I want you to write a program that reads the above junk and stores it for > querying. I know the "above junk" is just an example, and so might not actually represent the actual implementation, but when you say: > rm script=<text Path> Are you saying the command would be implemented as a script, or what? I'm just curious how you plan to implement commands in the plugins. The descriptor file you specified seems fine to me, and I agree... no XML. James |
|
From: Navid G. <go...@at...> - 2003-04-16 00:41:43
|
Ok Manan, Here's one thing you could do: We currently have this thing called plugins. A plugin basically expands what trap can do. For example a Unix plugin might have the ability to erase files, rename files, move files, etc..A samba plugin could be able to edit samba password file, add computers to allowed hosts for samba, etc... Now when the admin wants to add commands to be executed by the clients he needs to know what plugins are available. To do that the server will need a description file for each plugin. The description file basically has a sentence about what the plugin is for, A list of available functions, a description of functions, and a script telling the gui what to display (not important for now). Here's an example for a unix plugin that has the ability to erase and symlink files: Description=Plugin that performs various unix commands. Functions=rm,ln rm description=Erases files or directories ln description=Creates a symlink to an already existing file/directory rm script=<text Path> ln script=<text Source><text Destination><bool Symbolic> I want you to write a program that reads the above junk and stores it for querying. First step: Tell me how the format of the descriptor file is. You can make it up as long as it's easy for people to create. NO XML!!!. You can assume each plugin has it's own description file. IE if there is a plugin called unix.o then there will be a description file for it called unix.desc (or something like that). Either way you would store the plugin name as well as the above sample descriptor file in memory. Basically you'll just read it in and store it. Not interpreting most of it. I'll let you know what you need to know to program for trap once you come up with a descriptor file format. Make it formal and accruate since it will go on the webpage as sort of a tutorial for other developers who want to create a plugin. If you don't wanna do it/don't have time that's fine. Just let me know. James you got any corrections/additional info? Navid |
