How do I install this service_wrapper for mongrel/rails on my windows server? - ruby-on-rails-3

I have been given the unpleasant task of installing a Rails 3 app I have written on Windows Server 2008 (definitely not my choice - was promised a linux server but I.T. pulled the rug out at the last minute so please don't suggest a change in environment as a solution).
I followed the instructions on this blog post (with a few minor modifications) and now actually have my app up and running under Windows/IIS (proxying mongrel) after a great deal of frustration. The only thing remaining is to get mongrel running as a service.
Unfortunately the mongrel gem has not been kept up-to-date for Rails 3 and while I can get the app running under mongrel at the command line I am unable to use mongrel_service to get the app running as a service.
The solution to this appears to be to use the service_wrapper project on github which has been mentioned in this previous question. The project is not yet complete but apparently functional but comes without documentation/binaries. I have looked through the source-code and don't really understand what is it/how it works so was wondering if someone can point me in the right direction (or, even better, walk me through how) to get this installed.
So close, yet still so far.....

Alright I have this worked out (with a little help from luislavena himself - thanks).
Download service_wrapper-0.1.0-win32.zip from https://github.com/luislavena/service_wrapper/downloads and extract service_wrapper.exe from bin/. I extracted it to C:\service_wrapper.
Next set up a configuration file. I used the hello example and modified it for my app then placed it in the C:\service_wrapper directory.
; Service section, it will be the only section read by service_wrapper
[service]
; Provide full path to executable to avoid issues when executable path was not
; added to system PATH.
executable = C:\Ruby192\bin\ruby.exe
; Provide there the arguments you will pass to executable from the command line
arguments = C:\railsapp\script\rails s -e production
; Which directory will be used when invoking executable.
; Provide a full path to the directory (not to a file)
directory = C:\railsapp
; Optionally specify a logfile where both STDOUT and STDERR of executable will
; be redirected.
; Please note that full path is also required.
logfile = C:\railsapp\log\service_wrapper.log
Now just create the service with
sc create railsapp binPath= "C:\service_wrapper\service_wrapper.exe C:\service_wrapper\service_wrapper.conf" start= auto
(watch for the spaces after binPath= and start=. It won't work without them)
Then start it with
net start railsapp
And you're home and hosed!

I ought to contribute due to this article. For config of using bundle exec, use the following:
Note that I am setting up rubyCAS! it's a great OpenCAS authentication mechanism!!!
; Service section, it will be the only section read by service_wrapper
[service]
; Provide full path to executable to avoid issues when executable path was not
; added to system PATH.
executable = C:\Ruby\bin\ruby.exe
; Provide there the arguments you will pass to executable from the command line
arguments = D:\rubycas-server bundle exec rackup -s mongrel -p 11011
; Which directory will be used when invoking executable.
; Provide a full path to the directory (not to a file)
directory = D:\rubycas-server
; Optionally specify a logfile where both STDOUT and STDERR of executable will
; be redirected.
; Please note that full path is also required.
logfile = D:\rubycas-server\log\service_wrapper.log

Related

Installing Google Adwords Api Library (using docker)

Googles documentation on installing the library, found here: https://github.com/googleads/googleads-php-lib/blob/master/README.md#getting-started, instructs us to copy adsapi_php.ini, as constructed here: https://github.com/googleads/googleads-php-lib/blob/master/examples/AdWords/adsapi_php.ini, to your home directory.
I filled out the necessary variables in the .ini, and I am using docker so I have placed this file inside my container at /var/www/home/node/ and when I run the command composer require googleads/googleads-php-lib I am given the following error in the command prompt:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for googleads/googleads-php-lib ^37.1 -> satisfiable by googleads/googleads-php-lib[37.1.0].
- googleads/googleads-php-lib 37.1.0 requires ext-soap * -> the requested PHP extension soap is missing from your system.
To enable extensions, verify that they are enabled in your .ini files:
- /usr/local/etc/php/php.ini
- /usr/local/etc/php/conf.d/adsapi_php.ini
- /usr/local/etc/php/conf.d/docker-php-ext-pdo_pgsql.ini
- /usr/local/etc/php/conf.d/docker-php-ext-sodium.ini
- /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.
Installation failed, reverting ./composer.json to its original content.
I assumed the issue was my adsapi_php.ini was simply in the wrong location as it contains what I believe is necessary to avoid the above issue, but I have tried placing it in several different places and yet I always get the same error.
Any help would be appreciated!
Just try to edit php.ini inside docker (docker exec -t {container} bashand enable there the extenstion soap

Install mozroot-certdata package on a read only root file system

I have an established yocto build which I'm now trying to switch over to having a root file system (eg. EXTRA_IMAGE_FEATURES += "read-only-rootfs").
However I'm running into an issue with a recipe in the meta-mono layer: mozroot-certdata. I see the culprit is the pkg_postint script (http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mozroot-certdata/mozroot-certdata_1.0.0.bb) which needs to modify the root file system on first boot which the build system is correctly flagging as impossible with a read only root file system:
ERROR: The following packages could not be configured offline and rootfs is read-only: ['mozroot-certdata']
My question is: is there a way to get these mozroot certs installed and configured with mono during the build process, such that the root file system does not need to be modified at boot/run time?
Well, I had a brief look at this late this summer, as I'm also using a read-only rootfs. The problem is that mozroot.exe is hardcoded to write into /usr/share/.mono/certs and does not respect your sysroot. You could probably hack mozroot.exe to actually write the imported files into the sysroot, though my time limit didn't allow me to try this (and neither have I ever looked into mono at all...).
My solution was instead to do the import at every boot. (It could also be done only once, but then the issue about updates come along). To achive this I made a bind mount on the directory where mozroot.exe wants to write the certdata.
Details of my solution
Add a file volatile-binds.bbappend with the following contents:
VOLATILE_BINDS += "\
/tmp/mono-certs /usr/share/.mono/certs \n\
"
That will make a bind mount from /tmp/mono-certs to /usr/share/.mono/certs, thus you'll be able to import the certs.
Then I added a service file and a mozroot-certdata_%.bbappend:
FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
DEPENDS += "mono-native"
SRC_URI += "file://mozroot-certdata.service \
"
inherit systemd
SYSTEMD_SERVICE_${PN} = "mozroot-certdata.service"
do_install_append() {
mkdir -p ${D}${datadir}/.mono/certs
mkdir -p ${D}${systemd_system_unitdir}
install -m 440 ${WORKDIR}/mozroot-certdata.service ${D}${systemd_system_unitdir}/mozroot-certdata.service
}
FILES_${PN} += "${datadir}"
# Empty the postinstallation script, as we can import the cert offline.
pkg_postinst_${PN} () {
# mono $D/usr/lib/mono/4.5/mozroots.exe --import --machine --ask remove --file $D/${sysconfdir}/ssl/certdata.txt
}
The service file mozroot-certdata.service:
[Unit]
Description=Import certficates to Mono
After=tmp-mono-certs.service
[Service]
Type=oneshot
ExecStart=/usr/bin/mono /usr/lib/mono/4.5/mozroots.exe --import --machine --ask-remove --file /etc/ssl/certdata.txt
[Install]
WantedBy=multi-user.target
is there a way to get these mozroot certs installed and configured with mono during the build process
Yes but it requires mosroots binary to be executable at rootfs creation time. See Post-Installation Scripts in documentation.
The 'else' branch in pkg_postinst is what gets executed at that time and if it succeeds, then the delayed postinst is not needed (and you shouldn't get a build error). mono-native recipe already exists so you should be able to depend on that and to fix the else branch in the pkg_postinst function so it finds native mono & mosroots.exe and writes to the correct place under $D.
As Anders mentioned this alone is not enough if you care about package-based upgrades.

Serving lua pages in apache windows

I have been using php for CGI scripting for some time now and recently got interested in lua.
I installed the latest version of luarocks(2.1.2) and the bundled version of lua(5.1.4). I wanted to start from the basics and hence installed cgilua(5.1.4-2) and all its dependencies using "luarocks install cgilua".
I am able to run simple lua scripts using the shebang line to point to my lua interpreter but when i use it to point to the cgi launcher "cgilua.cgi.exe" to run .lp files it just won't work. I edited my httpd configuration file to allow cgi execution in my htdocs and cgi-bin directory and used the cgi-script handler for .lp pages. I am trying to run the login.lp example in the cgilua examples directory. I even added the line "Content-type:text/html" to no avail. Executing the cgilua.cgi.exe file from the command line without arguments just closes the application with the message "cgilua.cgi.exe" stopped working".
Could anyone tell me what am I missing? Maybe the launcher is supposed to be used in a different way?
I don't suppose permissions have a part to play in this as in windows all users have at least read and execute permissions.
The url I'm trying to access is http://localhost/login.lp. My apache error log shows "Premature end of script headers: login.lp" with a 500 internal server error and the same thing if I access http://localhost/cgilua.cgi.exe
I don't know what your requirements are, but perhaps it will be easier to simply use apache's mod_lua.
http://httpd.apache.org/docs/trunk/mod/mod_lua.html

The local psql command could not be located

I'm following the instructions found here.
When I try to run $ heroku pg:psql or $ heroku pg:psql HEROKU POSTGRESQL_BROWN I recieve the following error message:
! The local psql command could not be located ! For help
installing psql, see local-postgresql
I can't find anything useful on the link it gives me (it just links to the instructions I was already using, but further down the page) nor can I find this error anywhere else.
If I've missed anything you need to know to answer this, just let me know. I'm rather new to all this and teaching myself as I go.
I had same error even after installing Postgres locally.
But after seeing this
I saw that "pqsl" was not in the PATH so I then did
PATH=%PATH%;C:\Program Files\PostgreSQL\9.2\bin
which worked for me
I have since solved this myself. When I ran heroku pg:info it says the version number is 9.1.8, I was locally running 9.2
installing 9.1.8 and ensuring Path pointed to the appropriate folder solved the problem.
After you change the path, make sure to restart the terminal!
Set the PATH. To find out the PATH of your psql script (on mac) open the sql shell script from your finder in Applications/Postgres installation. This will give you a hint as to where it is installed. That opened a window which told me it is located here: /Library/PostgreSQL/8.4/scripts/runpsql.sh
Then, I set the PATH variable from the terminal window by typing:
$ PATH="/Library/PostgreSQL/8.4/bin:$PATH"
(depends on the location of your PostgreSQL installation, find your bin path first, another exp: /usr/local/Cellar/postgresql#9.6/9.6.8/bin)
OR.....
You can also connect to the shell by opening the shell directly from your postgres installation folder. Then enter the credentials. If you don't know the credentials, here is how to find them out:
$ heroku pg:info
=== HEROKU_POSTGRESQL_RED_URL (DATABASE_URL)
$ heroku pg:credentials HEROKU_POSTGRESQL_RED_URL
Top answer wouldn't work for me oddly, my system would not add the Path via cmd with administrator access (Not sure why).
So check this > Windows key > environment variables > system variables
And add the last line (your version may differ in the path)
Make sure you've installed the toolbelt as psql is installed by default.
However you also need to ensure you've installed a local copy of PostgreSQL; if you don't the toolbelt will be unable to find the native psql client.
Assuming you have installed a local copy of PostgreSQL, make sure you can execute psql from the command line directly (i.e make sure you PATH is set correctly ). If the command does not execute, check your PATH, if it does execute see if you can connect via the PSQL connection string provided in the Heroku control panel. If you can connect reinstall the toolbelt, if you are unable to connect provision another dev database and try again.
If there are still issues, I would suggest contacting Heroku support for assistance after verifying no API issues are listed on the status page located here.
I got rid if this annoying message on Windows by adding a path element without the spaces, i.e.
C:\Progra~1\PostgreSQL\9.4\data
instead of
“C:\Program Files\PostgreSQL\9.4\data”
I followed the instructions here: http://www.computerhope.com/issues/ch000549.htm, which worked for me if you prefer to go the point-and-click configuration of the PATH variable.
This type of error usually appears in the Windows environment, because if you do not update the PATH after installing Postgresql, heroku pg:psql command does not work.
So you need to update your PATH environment variable to add the bin directory of your Postgres installation. The directory will look like this:
C:\Program Files\PostgreSQL\<VERSION>\bin.
For more information, go to the Heroku in Local setup website:
heroku-postgresql: Local setup
I had the same problem and discovered that Heroku doesn't seem to provision the latest version of PostgreSQL by default. Where the Heroku Getting Started instructions said
heroku addons:create heroku-postgresql:hobby-dev
That provisioned a v10 database for some reason (which you can check by clicking on Heroku Postgres in the Add-ons tab of your dashboard). I deleted that database and provisioned a new database using the --version flag:
heroku addons:create heroku-postgresql:hobby-dev --version 11
As of now, at least, you can find the latest version of Postgres supported by Heroku at this link: https://devcenter.heroku.com/articles/heroku-postgresql#version-support-and-legacy-infrastructure
I'm writing this in early 2019, but according to the PostgreSQL website the next version (12) is "tentatively scheduled" for third quarter of 2019 so if you're reading this in late 2019 potentially the same problem will come up for v12 instead
On Mac you can use the following:
export PATH="/Library/PostgreSQL/12/bin/:$PATH"
The only solution that I found on Windows:
go to advanced system settings
go to environment variables
select Path variable and click Edit
add a new line and enter your bin directory path (C:\Program Files\PostgreSQL<version>\bin) and click ok
restart your terminal
enter your psql command (heroku pg:psql)

Debugging Solaris OS crash

I have access to a remote Solaris terminal which crashes occasionally, and I have to ask someone with physical access to boot the machine up, which it does successfully. I would like to know which tools/files should I look at to find out the cause of the crash so that I can make the necessary configuration changes and avoid it in the future.
What tools you can use will depend on what version of solaris you have running and what the actual problem
is. The first thing to do is check the system console (which it sounds like you don't have access to) and the /var/adm/messages file. This file is updated with system messages and the newest will appear at the end.
Next, you can look for a system core file. If a core file is created, it would be in /var/crash/hostname where "hostname" is the name of the machine.
If you have an actual core file in the /var/crash/hostname directory, this set of commands will give you a good
string to search google with:
# cd /var/crash/hostname
Replace "hostname" with the hostname of your machine.
# mdb -k unix.0 vmcore.0
If you have multiple core files, select the most recent version.
> ::status
This should give you a panic message, cut and paste that into google and see what you can find.
For more core file analysis read this:
http://cuddletech.com/blog/pivot/entry.php?id=965