Dale,
Can I use tODE in this context: 1) GemStone 3.1.0.6 (cannot upgrade right now) 2) I want to use my own scripts for starting/stopping gems and stones. I have a full bunch of scripts for managing my stones and I would like to continue doing so. So I wonder how easy is to install tODE in stone side and everything.... 3) I already have my stones (I won't be creating from scratch). 4) I do NOT use DataCurator user (but a custom user) 5) My stones, conf files, and everything is at a different location that the layout of GsDevKit So... in other words... can I simply use tODE (as a first step) rather than the whole GsDevKit for my existing stones? _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Sun, Sep 13, 2015 at 9:37 PM, Mariano Martinez Peck <[hidden email]> wrote:
6) I do not use Git but Monticello + Metacello 7) 70% of my usage is for debugging continuations from Object Log. Can I debug this from tODE? Thanks!
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
The short answer is yes ... You will want a gsDevKitHome (dev
branch) installation to provide the disk structure expected by tODE
(you'll want to define the $GS_HOME env variable -in you netldi
context - so that tODE can find disk artifacts) , but other than
that tODE is just another application running in the stone.
If you don't use the gsDevKitHome scripts, then you will have to create the pharo tODE client manually and install tODE manually ... The easiest route would be to install a throwaway stone by following the instructions in the dev branch readme[1]. Since you've got GemTools and GemStone running in your system you shouldn't have to install anything but you can glance at the osPrereqs script to see if there any bits you might have missed (as questions if you're not sure) using this command: installServer tode 3.1.0.6 this will create a todeClient image, create a stone directory structure called tode that you will use for attaching your pre-existing stones to ... once the process is complete you can shutdown the tode stone and stop the tode netldi .... gsDevKitHome uses the following scripts to install tODE: $GS_HOME/tode/sys/default/server/scripts/upgradeGLASS.ws $GS_HOME/tode/sys/local/server/scripts/installMetacello.ws $GS_HOME/tode/sys/local/server/scripts/installGLASS1.ws $GS_HOME/tode/sys/local/server/scripts/installTode.ws If you are using a reasonably recent GLASS1, then you can just do the installTode.ws step in your stone logged in as your user and do the following (which is the contents of installTode.ws :): GsDeployer bulkMigrate: [ Metacello new baseline: 'Tode'; repository: 'github://dalehenrich/tode:dev/repository'; onConflict: [ :ex | ex allow ]; get; load: 'GemStone Dev'; lock ] For the final step, hooking up to your disk structure I will have to do a little bit more research/experimentation .... but you might want to do the tODE install in a sandbox stone and run some of your own unit tests to make sure that tODE doesn't perturb your system I'll now comment in-line about your bullet points... Dale [1] https://github.com/GsDevKit/gsDevKitHome/tree/dev#open-source-development-kit-for-gemstones-64-bit- On 9/13/15 5:42 PM, Mariano Martinez
Peck via Glass wrote:
I use tODE in all versions of GemStone ... tODE is marginally functional in 2.4.x (not recommended - trigger occasional SIGSEGV in gci interface) but in 3.x the system doesn't crash ... I just have been using tODE with 3.2 and 3.3 more than 3.0.1 and 3.1.x, but everything should work ... if you hit a problem I would like a bug report and stack (if there is one) - you can use ALT-SHIFT-P to create a text version of the debugger stack and inspector windows (or any other window for that matter) to produce your bug report. covered this one:) no problem shouldn't be a problem ... currently I don't prompt for a password (the passwords are embedded in the description file), but I intend to implement that functionality soon (I'd accelerate that for you:) not a problem ... tODE has some directory paths that will need to point into a gsDevKitHome directory structure ... but the stone does not have to reside there ... tODE doesn't require git ... it has tool level support for git ... Yes. there is an `ol view` command that brings up an object log viewer and you can debug continuations using a menu item ... take a look at the `ol` command man page `man ol` as there a number of filtering options built in (like --age) that you might find useful ... of course if you have issues or ideas for new `ol` command features I'd like to hear about them. Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Mon, Sep 14, 2015 at 12:05 PM, Dale Henrichs via Glass <[hidden email]> wrote:
OK, I got the dev branch and made the variable exports.
OK, server installed and even todeClient generated :)
OK, I run this on my already existing stone which is supossed to have a recent GLASS1.
This is where I am now. I am trying to set into tODe an already existing stone.. I tried this way which you told me long ago: (OGStandardSessionDescription new name: 'mariano'; stoneHost: 'localhost'; stoneName: 'mariano'; gemHost: 'localhost'; netLDI: '40001'; userId: 'marianopeck'; password: 'xxx'; backupDirectory: '/opt/gemstone/product/seaside/data/backups/'; yourself) exportTo: TDShell sessionDescriptionHome. But it fails because #sessionDescriptionHome doesn't exist anymore Any clues?
Cool!
At some point I recall something that was assuming I was running with DataCurator. I think it was some of the GsDevKitHome scripts, which I won't be using so far. So so far I think I am ok.
OK.
ok
Great!
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Yep ... but I'm in the middle of lunch I still need to work out all
of the details .. part will be to use the file created for your
example stone.
$GS_HOME/tode/sys/local/client/descriptions contains a description file that can be editted with the details of the stone in which you installed tODE manually ... at least this should get you logging in ... There may be a gotcha or two withe getting your /home and /sys environments set up -like `ls` might not work ... but the commands probably will - and that will take a bit of looking ... after lunch:) Dale On 09/14/2015 12:53 PM, Mariano
Martinez Peck wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Okay, here's the skinny on the description (you may already have figured
it out: TDSessionDescription{ #name:'gs_3281', #stoneHost:'foos.gemtalksystems.com', #stoneName:'gs_3281', #gemHost:'foos.gemtalksystems.com', #netLDI:'gs_3281_ldi', #gemTask:'gemnetobject', #userId:'DataCurator', #password:'swordfish', #backupDirectory:'/export/foos1/users/dhenrich/gsDevKitHome/gemstone/stones/gs_3281/backups/', #snapshotDirectory:'/export/foos1/users/dhenrich/gsDevKitHome/gemstone/stones/gs_3281/snapshots/', #gemstoneVersion:'3.2.8.1', #serverGitRoot:'/export/foos1/users/dhenrich/gsDevKitHome/gemstone/stones/gs_3281/git', #serverTodeRoot:'/export/foos1/users/dhenrich/gsDevKitHome/tode'} You'll want to consider what you put into the name:, stoneHost:, stoneName:, gemHost:, netLDI:, backupDirectory:, snapshotDirectory:, serverGitRoot: and serverTodeRoot: fields (my $GS_HOME is /export/foos1/users/dhenrich/gsDevKitHome). You will want a separate copy of the description for each stone where the file name should match the description name which should match the stone name. Keep all of the copies in $GS_HOME/tode/sys/local/client/descriptions and the tODEClient will find new ones and make them available on the tODE system menu. The stoneHost:, stoneName:, gemHost:, and netLDI: fields should match the stone info you are connecting to. The serverTodeRoot: field is most likely fine ($GS_HOME/tode). You can clear serverGitRoot: (empty string) since you don't use git. You'll want to change the backupDirectory: and snapshotDirectory: fields to point to a pair of directories that is unique to each stone ... this is where the tODE backups and snapshots are stored ... I assume you will want to keep these separate from your production backup directories ... I'll send a separate mail about hooking up to the directory structure... Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Mariano,
If you look in the $GS_HOME/bin/installTodeStone script you will see (at the end) the `installTode $stoneName` command is sent to the pharo vm via the command line and this ends up invoking the following tODE shell builtIns: script --script=installServerTode script --script=installServerTode2 Which themselves cause tODE commands to be loaded from the two files `installServerTode` and `installServerTode2` which can be found in the $GS_HOME/tode/sys/default/client/scripts directory (you can arrange to customize these installation steps by putting the modified copies in the $GS_HOME/tode/sys/local/client/scripts). The `installServerTode` performs the `installServer` command which automatically loads the 4 .ws files I told you about in a previous email .. so you've alread done this step. The `installServerTode2` performs the following commands: bu backup --safely tode.dbf # make a backup of initial tODE install bu snapshot --safely tode.dbf # make a snapshot of initial tODE install script --script=setUpSys # set up the in-image tODE /sys structure bu backup --safely home.dbf # backup of initial tODE install with /sys structures in place bu snapshot --safely home.dbf # make a snapshot of initial tODE install with /sys structures in place These guys are basically making before and after backups for the `setUpSys` script (which itself is found in same directory): # Set up /sys node structure mount --todeRoot sys/default /sys default mount --todeRoot sys/local /sys local mount --todeRoot sys/stones /sys stones # ensure that --stoneRoot directory structure is present /sys/default/bin/validateStoneSysNodes --files --repair mount --stoneRoot / /sys stone # Define /home and /projects based on a composition of the /sys nodes mount --stoneRoot homeComposition.ston / home mount --stoneRoot projectComposition.ston / projects commit cd The `mount` command links a directory on disk to an object the `/` object structure in tODE. `--todeRoot` references the serverTodeRoot: field from the TDSessionDescription. The implication of the first three commands is that you can access $GS_HOME/tode/sys/default, $GS_HOME/tode/sys/local and $GS_HOME/tode/sys/stones from within the tODE shell using the paths: /sys/default, /sys/local, /sys/stones. With $GS_HOME/tode/sys/default, it is possible to execute the $GS_HOME/tode/sys/default/bin/validateStoneSysNodes command in tODE. The validateStoneSysNodes command creates a set of stone specific disk artifacts that are used to define the '/home' and '/project' object structures along with the `/sys/stone`which makes it possible to access the $GS_HOME/tode/sys/stones/<stone-name> directory without having to query the name of the running stone ... makes writing stone independent scripts real easy ... `/sys/default/bin/validateStoneSysNodes -h` will bring up the man page for this command in tODE ... After validateStoneSysNodes is run, `/sys/stone`, `/home`and `/projects` are mounted. `/home` is where you can access and share scripts/objects and `/projects`is where the projectEntries are found for your stone (the project list is created based on the list of project entries found in `/projects`. `/home` is actually a composition of the disk directories $GS_HOME/tode/sys/default/home, $GS_HOME/tode/sys/local/home, and $GS_HOME/tode/sys/stone/<stone-name>/home. If you want to share a script with other stones you can copy it to /sys/local/home and all stones will see it ... By default scripts created in your home directory are created on disk in /sys/stone/home. If you want to see how the composition works/is specified, `edit /sys/stone/homeComposition` to see the Smalltalk code that is invoked when you access /home ... Basically you just need to execute `script --script=setUpSys ` command .... BUUUUUUT you need to make a decision or two first ... If you want to share the SAME stone directory structure between stones, then you will need to arrange to override the default definition of for the --stoneRoot option used above .... this is possible but can be a bit tricky and possibly error prone (as in tODE might assume things that wouldn't be true in your case). In addition to this sticky wicket, I actually think you will be happier if you arrange to use a separate stone directory structure for each of your stones (I worked in a shared environment for quite awhile and the home directory becomes crowded real fast). If you want to do it this way, let me know and I will do a bit more research and get back to you.. To create the directory structure you only need to copy the directory that was created when you created the initial stone using gsDevKitHome ... was it called mariano? And you can do that by executing the following bash shell command for each stone (like you have a description file for every stone): cp -r $GS_HOME/tode/sys/stones/mariano $GS_HOME/tode/sys/stones/<stone-name> Where <stone-name> matches the stoneName: field in your description file. Soooooo, to hook up your stone to the directory structure, execute the following tODE shell script: script --script=installServerTode2 and you'll be ready to rumba... the script does a backup before running the setUpSys commands so if we run into problems in your sandbox we can restore from backup and try again ... Let me know how it goes. Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Mon, Sep 14, 2015 at 6:01 PM, Dale Henrichs <[hidden email]> wrote: Okay, here's the skinny on the description (you may already have figured it out: Yes, that was clear. You'll want to consider what you put into the name:, stoneHost:, stoneName:, gemHost:, netLDI:, backupDirectory:, snapshotDirectory:, serverGitRoot: and serverTodeRoot: fields (my $GS_HOME is /export/foos1/users/dhenrich/gsDevKitHome). Yep, I did that, and I could connect :) Even to a remote stone! The stoneHost:, stoneName:, gemHost:, and netLDI: fields should match the stone info you are connecting to. Yes, I let that one. You can clear serverGitRoot: (empty string) since you don't use git. Done.
mmmm I would use the same folder I guess. Is there any risk of having the same directory for both (my own daily backups) than those performed by tODE? I'll send a separate mail about hooking up to the directory structure... Cool, thanks! _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 09/14/2015 03:12 PM, Mariano
Martinez Peck wrote:
the only risk is that you would want to avoid the possibility of overwriting a production backup from tODE .. by accident ... there are some tests in the image that create backups also there are some standard scripts that use home.dbf and tode.dbf backup names (I describe those scipts in my follow-on mail) ... there is a command `bu remove` for removing backups as well:) so at the end of the day, it is up to you ... it isn't hard to change where you want the tODE backups to go, so if you are comfortable with sharing the directory then it won't be a problem ... I tend to be conservative when it comes to interacting with production, especially when making "recommendations":) Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Mon, Sep 14, 2015 at 7:03 PM, Dale Henrichs <[hidden email]> wrote: Mariano, Cool. Thanks for the explanation. I get it. The `installServerTode2` performs the following commands: ok... `/home` is actually a composition of the disk directories $GS_HOME/tode/sys/default/home, $GS_HOME/tode/sys/local/home, and $GS_HOME/tode/sys/stone/<stone-name>/home. If you want to share a script with other stones you can copy it to /sys/local/home and all stones will see it ... By default scripts created in your home directory are created on disk in /sys/stone/home. If you want to see how the composition works/is specified, `edit /sys/stone/homeComposition` to see the Smalltalk code that is invoked when you access /home ... Ufff this is nice. I really would like to save out scripts to easily run in different stones!
Perfect. Pufffff you know what? I was afraid of doing that CP because I thought this folder was the one containing all the stone info as well (extent, env files, etc etc). But I just realized that is elsewhere: $GS_HOME/gemstone/stones ... what a relief. That was the main confusion. Didn't know tode has it's own directories too. Also..I did a grep -R to be sure the stone name was not used anywhere inside the files inside the folder (those ston files), and there is none , so we are safe :) Where <stone-name> matches the stoneName: field in your description file. Damn...I am running out of disk space in this small SSD....grrr... Either I trust and do not do backups (and I call setUpSys directly, and if screw up I use time machine), or .... we add compressed backups. I tried: 'man bu backup' but I do not see any option like --compressed which would be super cool :) and you'll be ready to rumba... the script does a backup before running the setUpSys commands so if we run into problems in your sandbox we can restore from backup and try again ... OK, tomorrow I will try later with setUpSys without backups... Thanks! _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 09/14/2015 04:05 PM, Mariano
Martinez Peck wrote:
Shoot! I've been meaning to add a --compressed option to the `bu` command ... I've made a note ... setUpSys shouldn't do anything that catastrophic if it fails and we can probably repair at the object level if it does --- I'm glad that you are seeing and appreciating the value of the independent tODE structure! Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Mon, Sep 14, 2015 at 8:33 PM, Dale Henrichs <[hidden email]> wrote:
Should I open an issue?
I tried but I get tode 1 > script --script=setUpSys Topez ERROR: a TodeCommandError occurred (error 121000), File or directory not found: '$GS_HOME/tode/sys/default' But the directory DOES exist, as I can try it from my command line: % ls -la $GS_HOME/tode/sys/default total 0 drwxr-xr-x 10 mariano staff 340 Sep 14 13:45 . drwxr-xr-x 6 mariano staff 204 Sep 14 13:45 .. -rw-r--r-- 1 mariano staff 0 Sep 14 13:45 README.md drwxr-xr-x 4 mariano staff 136 Sep 14 13:45 bin drwxr-xr-x 4 mariano staff 136 Sep 14 13:45 client drwxr-xr-x 5 mariano staff 170 Sep 14 13:45 home drwxr-xr-x 4 mariano staff 136 Sep 14 13:45 pharo drwxr-xr-x 20 mariano staff 680 Sep 14 13:45 projects drwxr-xr-x 3 mariano staff 102 Sep 14 13:45 server drwxr-xr-x 8 mariano staff 272 Sep 14 13:45 templates
Yes! that very much makes sense. I don't remember it like that when I last tried tODE.... Good design decision. Cheers, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
BTW...there is no man entry for 'script'. Doing 'man script' yields a key not found error. Thanks, On Mon, Sep 14, 2015 at 10:33 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On 9/14/15 6:33 PM, Mariano Martinez
Peck wrote:
yes please... I'm going to guess that GS_HOME is not defined ... it needs to be defined in the shell when you start your netldi run this tODE shell command : eval `{System clientEnvironmentVariable: 'GS_HOME'. System gemEnvironmentVariable: 'GS_HOME'}`; edit Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On 9/14/15 7:22 PM, Mariano Martinez Peck wrote: > BTW...there is no man entry for 'script'. Doing 'man script' yields a > key not found error. Hmmm ... `script` is a built-in on the client side and runs without connecting to the server ... I suppose I should eventually fix that:) Anyway `script -h` will give you help and builtIns give you a list of the commands that are built-in.. Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Tue, Sep 15, 2015 at 11:39 AM, Dale Henrichs <[hidden email]> wrote:
In GsDevKitHome issue tracker or is there a separate one for tODE?
mmmm i get this: tode 1 > eval `{System clientEnvironmentVariable: 'GS_HOME'. System gemEnvironmentVariable: 'GS_HOME'}`; edit [82042625 sz:1 Array] anArray( anArray( '/Users/mariano/gsDevKitHome', nil)) tode 1 > script --script=setUpSys Topez ERROR: a TodeCommandError occurred (error 121000), File or directory not found: '$GS_HOME/tode/sys/default' mmm why it cannot get the variable...mmm I must run now...will be back later _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 09/15/2015 08:10 AM, Mariano
Martinez Peck wrote:
Use the tODE issue tracker[1] [1] https://github.com/dalehenrich/tode/issues
Okay ... GS_HOME is defined in your client (the pharo client) and not defined in the gem (this the error) ... the environment variables for a gem are inherited from the netldi process (netldi forks the gems) and the netldi inherits the envirnment variables from the shell in which it was started ... presumably you started the netldi long before GS_HOME was defined ... Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 09/15/2015 10:05 AM, Dale Henrichs
wrote:
we can get around the use of GS_HOME if you don't want to restart the netldi ... to debug a TodeCommandError use the built-in tODE shell command `debugMode --set` ... then when you get a TodeCommandError a debugger will come up instead of the simple error message - that way we can get more detail on where $GS_HOME is being used ... Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Hi Dale, no, that's not the case. Just to confirm, I killed netldi, restarted iTerm, and re-start everything. Same problem. And it's not only tode, but gemTools too is not able to get that. I am using zsh and I have defined: export GS_HOME=/Users/mariano/gsDevKitHome export PATH=$GS_HOME/bin:$PATH everywhere: in ~/.zshrc ~/.zshenv and ~/.zshprofile no luck. The way I start netldi is this: su $RUNASUSER -c '$GEMSTONE_INSTALLATION/bin/startnetldi -g -a $GEMSTONE_USER -n -P $NETLDI_PORT -l $APPLICATION_LOG_DIR/netldi$APPLICATION_NAME.log netldi$APPLICATION_NAME > $GEMSTONE_LOGDIR/netldiStartup.log 2>&1' And a "ps -fea | grep netld" with a started netldi looks like this: 501 4848 1 0 3:20PM ?? 0:00.01 /opt/gemstone/GemStone64Bit3.1.0.4-i386.Darwin/sys/netldid netldimariano -g -n -amariano -P40001 -l /debris/Sites/mariano/gemstone/log/netldimariano.log I am trying to simulate this from my terminal but it works correct: % sudo su mariano -c 'echo $GS_HOME' /Users/mariano/gsDevKitHome Still, gems cannot get it. Any quick idea before I dig deeper? _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
OK, forget that question.. the problem was the "-m" passed to "su" .... grrr.. ok...back to task... On Tue, Sep 15, 2015 at 3:28 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |