GsDevKit_home newbie questions

Hi all,

I have installed GsDevKit_home on my Mac and managed to get the Seaside counter example working. Since I am a complete newbie to GsDevKit_home and tODE I have a ton of questions. ;-)

First, is GsDevKit_home only meant for development purposes or also for use on a production server?

I could not get Seaside working using port 1750 as used in „Getting started with Seaside“. When I used port 7100 it worked.

However, when I restarted my Mac, it stopped working. I guess I need to restart the stone.

I tried „startStone -b seaside_34“.

The stone started, however the following error is printed to stdout:

waitstone[Error]: Network service !#dir:/Users/bernhard/Documents/GsDevKit_home/server/stones/seaside_34/logs#log:%N%P.log#server!seaside_34 was not found.
Network lookup failure; could not find server 'seaside_34' on host 'MacBookProRetina.local' because file not found: /opt/gemstone/locks/seaside_34..LCK;  service seaside_34 not found ; NetLDI service 'gs64ldi' not found on node 'localhost6' port 50377 :
connect(7,::ffff:127.0.0.1,port=50377) failed with errno=22,EINVAL, Invalid argument (programmer error)

Is that something to be worried about?

While netldi, stoned and three gem processes are started, Seaside does not listen on port 7100. Why is that?

Shouldn’t at least one of the gems serve Seaside requests?

How can I start Seaside so that it survives restarting the stone?

One final question, I guess for production I’d need a web server like nginx or Apache in front of the stone, right?

Thanks for your terrific work!

Bernhard
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Mariano,

Yes, I’d be very interested to see how your scripts look like, for init.d,

and also how you load BaselineOfSeaside

and your Seaside gem scripts. There are so many different variants, I must admit it is a bit confusing. :-)

Thanks for your help!

Bernhard

> Am 24.11.2017 um 03:11 schrieb Mariano Martinez Peck <[hidden email]>:
>
>
> On Thu, Nov 23, 2017 at 7:58 PM, Bernhard Pieber via Glass <[hidden email]> wrote:
> Hi all,
>
> Hi Bernhard, nice to see you here.
>
>
> I have installed GsDevKit_home on my Mac and managed to get the Seaside counter example working. Since I am a complete newbie to GsDevKit_home and tODE I have a ton of questions. ;-)
>
> First, is GsDevKit_home only meant for development purposes or also for use on a production server?
>
>
> I am not the author, but I would say on production too for sure.  In fact, its client vs server architecture makes it very nice for that approach. For example, I install server side of GsDevKit_home on my servers and then client side (with tODE client) in my developer / sysadmin machines.
>
> I could not get Seaside working using port 1750 as used in „Getting started with Seaside“. When I used port 7100 it worked.
>
> No clue. I use Seaside in a different way (I do not use the Seaside project from GsDevKit but instead I simply load BaselineOfSeaside and then I have my custom scripts for the seaside gems).
>
>
> However, when I restarted my Mac, it stopped working. I guess I need to restart the stone.
>
> Yes. On production, I made some init.d kind of script to start/stop/stat my stones (I can share that script if you want), but some people don't like to auto-start stones at OS boot.
>
> I tried „startStone -b seaside_34“.
>
> That's correct.
>
> The stone started, however the following error is printed to stdout:
>
> waitstone[Error]: Network service !#dir:/Users/bernhard/Documents/GsDevKit_home/server/stones/seaside_34/logs#log:%N%P.log#server!seaside_34 was not found.
> Network lookup failure; could not find server 'seaside_34' on host 'MacBookProRetina.local' because file not found: /opt/gemstone/locks/seaside_34..LCK;  service seaside_34 not found ; NetLDI service 'gs64ldi' not found on node 'localhost6' port 50377 :
> connect(7,::ffff:127.0.0.1,port=50377) failed with errno=22,EINVAL, Invalid argument (programmer error)
>
> Is that something to be worried about?
>
>
> I don't think so, I see same kind of printing too...which it would be nice to be ignored. What is important is that you can see if netldi was started correctly. COnsole should say something like:
>
> startnetldi[Info]: GemStone server ' seaside_34_ldi' has been started, process 20927
>
> You can also look to `$GS_HOME/server/stones/seaside_34/logs/netldi.log`
>
> Nevertheless...if you see the seaside gems alive, then it likely means that netldi was working...
>
>
> While netldi, stoned and three gem processes are started, Seaside does not listen on port 7100. Why is that?
>
> I really haven't used the Seaside scripts that come with GsDevKit's Seaside. Maybe the Seaside adaptors were not started?
>
> Shouldn’t at least one of the gems serve Seaside requests?
>
> By default, 3 gems are started (you can have thousands running) and so, each should be able to serve Seaside requests.
>
> How can I start Seaside so that it survives restarting the stone?
>
> In my case, I have the init.d which starts the stone and then calls bash scripts to start seaside gems.
>
>
> One final question, I guess for production I’d need a web server like nginx or Apache in front of the stone, right?
>
> On production, yes, I would, for sure. I use nginx where I can set HTTP2, SSL cert, compression, caching, logging, try to prevent DoS attack, and many features more.
> And then from Seaside side you should use the FastCGI adaptors. Then at nginx all you do is to redirect to a list of upstreams...
>
> Hope this helps...
>
>
>
> Thanks for your terrific work!
>
> Bernhard
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com

On Fri, Nov 24, 2017 at 5:47 AM, Bernhard Pieber <[hidden email]> wrote:

Hi Mariano,

Yes, I’d be very interested to see how your scripts look like, for init.d,

This is very simple file... btw I just remember that I let Seaside gems to be started by monit rather than init.d.. 

I will also send you a monit example just in case (this is intended to be used with my seaside scripts and with FastCGI but you can get an idea).

 

and also how you load BaselineOfSeaside

Something as simple as:

Metacello new

   baseline: 'Seaside3';

   repository: 'github://SeasideSt/Seaside:v3.2.4/repository';

   onLock: [ :ex :loaded :incoming | ex honor ];

   get;

   load: #('Core' 'Zinc-Seaside' 'Javascript' 'JQuery' 'JSON' 'FastCGI' 'Email' 'Filesystem' 'CI');

   lock.

In *my opinion* GsDevKit seaside [1] does not make anymore as for holding the CODE. The official repository for seaside [2] now supports gemstone and you  can use latest version etc. 

In the README you can see how to install in GemStone. 

What does make sense is to have nice Seaside scripts for managing gems , maitainance, etc. That's why I think that [1] still makes sense but as for holding scripts mostly but not for seaside code. 

I am wathcing the doc on seaside scripts [3] and I imagine they will point back to the scripts in $GEMSTONE/seaside/bin/*.   Those scripts are the one I have been forking / maintaining / improving and using since a loooong time.  

If someone is really interested  we could:

1) analyze my changes with upstream / original scripts and see if you agree with the improvements (I guess you would)

2) publish my scripts into [1] and stop using this project for code (or to a new repo?)