Re: [gomd-devel] <IRC> interesting IRC chat session about gomd...

[Matthias Rechenburg]

Hi from Matt :)

read the mails+irc-log about auth + checkpointing and
here are my comments.

about the auth:
I prefer the auth.conf for gomd for now 
(later we can see if we improve this)
The feature should combine acl.conf + scx.conf

about the checkpointing:
It is a vey good idea to add this feature to the gomd :) !
The users will love it.
I just think that automatically checkpointing the processes
which needs most of the cpu will not work so well.

Here are my thoughts about the chpox-support :

1) we need a register, unregister and list-register processes
   register should automatically check the binary program
   with ldd to find out which libraries needs to be added
   to chpox before. -> even if it is a script to register it 
   needs some libs for e.g. bash

2) unregister should unregister the process but not the libs
   because they may be needed by other registered processes 

3) the registration will use a dump-file with the process + pid 
   name to be sure to have unique names for the process dumps

4) if there are registered processes for checkpointing the gomd
   should send the checkpoint signal to them in an intervall
   (timeout can be static first, maybe later it would be nice if one
   can configure it per process)

5) if a process is checkpointed the gomd should/must move its
   dump file to a diffrent name containing a timestamp.
   Otherwise the next checkpoint will overwrite the current dump file
   even if the registered process is crashed but still alive. This will
   make it "un-restorable"   -> so we need timestamps for each 
   checkpointed process-dump to be able to restore it at any given
   time (any given time a checkpoint was written).
   We have to take care of the disk-usage with this feature because
   it may create a lot of dumps which are not removed yet.

6) we have to think about how and when to remove process dumps

7) we should add a check if the chpox module is available, if not
   those register/unregister/checkpoint commands should be disabled
   or display a notice that the user have to install chpox first.
   This can be simply done by the gomd init script (insmoding chpox mod
   and check if it returns ok) and then start the gomd with an additional
   commandline parameter ....... just an idea.

If we have all this together the user can simple add checkpointing HA
to his/her processes. 

.... as usual just Matt's mind  ;)) 

stay tuned,

Matt


On Donnerstag 25 September 2003 21:32, Gian Paolo Ghilardi wrote:
> Hi all.
>
> This is the backlog for a nice IRC chat session.
> Thanks to roeles, Wim, halves for this nice session.
>
> Summary of the backlog:
> - add auth method to gomd to distinguish between users
> - security stuff
> - chpox implementation
>
> Byez.
>
> <rejected>
>
> REJ: hi all...
>
> ROELES: hi _rejected_
>
> REJ: hi roeles...
>
> REJ: just read your mails...
>
> ROELES: ah ,k
>
> ROELES: did I misunderstand the checkpoint-stuff
>
> ROELES: ?
>
> REJ: maybe my words were not so clear...
>
> REJ: the chpox stuff is a kenrel module + some userspace tools for
> checkpointing/restoring saved procs...
>
> HALVES:_rejected_: hi
>
> ROELES: ah
>
> REJ: hi halves... ;9
>
> ROELES: _rejected_: and you wanted gomd to have the userspace stuff?
>
> REJ: no...
>
> REJ: just only these tools in a practical way...
>
> ROELES: ah...
>
> ROELES: good idear
>
> REJ: the chpox stuff require that an user invoke manually the proc
> checkpoinitng...
>
> REJ: same situation for the proc restoring phase...
>
> ROELES: invoke it in the program that needs the checkpoints? or in another
> process?
>
> REJ: my idea is automtize the checkpointing phase...
>
> WIM:i think it's a very good idea to use that
>
> REJ: hi Wim... Thanks...
>
> REJ: :)
>
> WIM:cause manual checkpointing is .. bothersome to say the least
>
> * roeles agrees
>
> WIM::-)
>
> REJ: the implementation should be easy:
>
> REJ: 1)gomd gets the full PID list (yet done)
>
> REJ: 2)for each proc enter /proc/[PID] so he can know if the proc was
> migrated
>
> ROELES: that's yet done
>
> ROELES: you can ask on what node a certain process is, right?
>
> REJ: 3)for each proc gomd gets the nice (==priority) value (if the nice is
> changed, the user reniced the process)
>
> REJ: 3)for each proc gomd gets the CPU time
>
> REJ: 4)sort the procs list
>
> ROELES: ah
>
> ROELES: nice
>
> ROELES: _rejected_: what did you think about user-based authentication?
>
> REJ: 5)checkpoints only the procs with an high  value. Value is a function
> defined as F(isProcMigrated,niceAtStartup,isProcReniced,cpuTimeUsed)...
>
> REJ: roeles: do you want something like PAM?
>
> ROELES: _rejected_: ehm..just to be able to login.
>
> REJ: ok...
>
> ROELES: PAM == auth by ldap right?
>
> REJ: PAM = plggable auth module => ldam, system flat files,...
>
> REJ: s/ldam/ldap
>
> ROELES: that would be even better...but little more complicated
>
> REJ: the pwd will be sent without encryption...
>
> ROELES: hm
>
> ROELES: true
>
> REJ: I prefer to implement a gomd auth.conf file...
>
> REJ: the pwd will be sent as hash values...
>
> ROELES: but then the telnet interface will not allow login
>
> REJ: np...
>
> REJ: the idea:
>
> REJ: 1)client opens a telnet conn to a gomd
>
> REJ: 2)if gomd has strict-security-mode enabled...
>
> REJ: 3)gomd asks a user+pwd
>
> REJ: 4)gomd received teh clear infos...
>
> REJ: 5)gomd checks the auth...
>
> REJ: 6)gomd eventually closes the conn...
>
> REJ: in this way if an user sniffs the user+pwd value there will no great
> probs...
>
> REJ: obviously you cannot enable the SCX_ALL_COMMANDS_ENABLED macro...
>
> ROELES: uuh
>
> ROELES: yeah
>
> REJ: ok....
>
> ROELES: btw...
>
> REJ: CU later. I need some food... ;)))
>
> ROELES: wouldn't it be nice to say, try to look at openssl sockets? :)
>
> ROELES: -say
>
> REJ: simple telnet cannot use SSL...
>
>
>
> _______________________________________________
> gomd-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gomd-devel

-- 
E-mail  :  address@hidden
www     : http://www.openmosixview.com
an openMosix-cluster management GUI

The important thing is not to stop questioning.