Date: Fri, 13 Jul 2012 15:49:19 +0400 From: Aleksey Cherepanov <aleksey.4erepanov@...il.com> To: john-dev@...ts.openwall.com Subject: Re: Re: Aleksey's status report #10 On Fri, Jul 13, 2012 at 12:54:10PM +0200, Frank Dittrich wrote: > On 07/13/2012 11:19 AM, Aleksey Cherepanov wrote: > > Frank, please, look onto the script. > > The daemon part: > > Maybe you need to add something like > > killall -s 1 john > > so that all currently running instances update the .rec/.log/.pot file. > Otherwise you might push results that are (per default config settings) > almost 10 minutes older than they needed to be. > > If a user has differently named executable files, e.g. a john-omp for > formats where this makes sense), you'd need to remember the names of the > executable files used by your attacks, and send a signal 1 to all of them. > (Alternatively, if you can grab the process ID, you could also send the > signal to individual processed.) It makes sense. It would not be hard to implement but it could improve monitoring and respective coordination. In theory I could track pids and kill by pids but it is much harder. Thinking about pids and status I caught myself on idea that I intended to have a wrapper (with cli compatible with john) that would do (transparent) distribution that probably would not have sighup handler. I think I could assume that there would not be such wrappers. But killall would not be a problem in any case (except windows). > Also, unless I missed something, you'll currently use git add ... even > if nothing changed compared to the previous time your daemon ran. > (Most likely cause for that would be that the session finished, and you > already committed and pushed its changes before. > Should you somehow mark the attacks as finished when the .rec file > disappeared (a session could also have been completed in a few seconds, > so that you never found a .rec file for this particular session. It says "Everything up-to-date" and does not commit or push anything if files were not changed. So it adds changes by fact, i.e. only if there are real changes (not just modified modification date on file). By the way I realized that .rec files are not always portable: file paths, especially absolute, are not portable. But I could replace all paths with relative ones from the store's root. Though paths in john.conf would be harder to change. I missed that no .rec is the normal case. I assumed that it is always presented like .log and .pot. > Do we need to parse the end of the log file to see if the session > completed or if it has been aborted? I did not know how to distinguish finished session from just stuck. But there is log. And session file disappears. Both ways does not seem to be hard. I'd like to use both together. Is .rec files wiped out not before pot is written? May we loose some cracked password but think that session was ended? > Could/should you skip the git push, if none of your git commit commands > ended successful? If there is not 'add' then `git commit` fails because I specify all file names explicitly. If there are no commit then push does not do anything. Though there could commit made by other instance (for instance when creates new attack daemon sends status) but it does not matter who invokes push. On the other hand there should not be fails (except empty commits). Thanks! Regards, Aleksey Cherepanov
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.