Hostsharing Wiki - Benutzerbeiträge [de]

RubyOnRails

2012-09-07T09:26:07Z

Srv00-wiki:

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und mit einer sqlite Datenbankdatei eingerichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/www.example.org/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/www.example.org/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite HOST_LANG=de RAILS_ENV=production PASSWORD=geheim HOST=www.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/www.example.org/rails, oder erstellt dort eine Neue (rails ~/doms/www.example.org/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/www.example.org/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: www.example.org
attachments_storage_path: /home/doms/www.example.org/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/www.example.org/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/www.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/www.example.org/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/www.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/www.example.org/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'

Die Applikation ins Webroot einbinden:

cd ~/doms/www.example.org
# ggf. vorhandene Dateien sichern (oder nach ~/doms/www.example.org/rails/public kopieren),
mv htdocs htdocs.old
# und das entsprechende public/ Verzeichnis der Rails-Anwendung im Webroot verlinken.
# Standardmäsig /home/doms/www.example.org/rails/public,
# bei multi-site Anwendungen wie zena aber z.B. /home/doms/www.example.org/rails/site/www.example.org/public
ln -s /home/doms/www.example.org/rails/public htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/www.example.org/fastcgi-ssl/ und ~/doms/www.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-09-05T22:03:22Z

Srv00-wiki:

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und diese mit einer sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/www.example.org/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/www.example.org/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite HOST_LANG=en RAILS_ENV=production PASSWORD=geheim HOST=www.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/www.example.org/rails, oder erstellt dort eine Neue (rails ~/doms/www.example.org/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/www.example.org/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: www.example.org
attachments_storage_path: /home/doms/www.example.org/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/www.example.org/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/www.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/www.example.org/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/www.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/www.example.org/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'

Die Applikation ins Webroot einbinden:

cd ~/doms/www.example.org
# ggf. vorhandene Dateien sichern (oder nach ~/doms/www.example.org/rails/public kopieren),
mv htdocs htdocs.old
# und das entsprechende public/ Verzeichnis der Rails-Anwendung im Webroot verlinken.
# Standardmäsig /home/doms/www.example.org/rails/public,
# bei multi-site Anwendungen wie zena aber z.B. /home/doms/www.example.org/rails/site/www.example.org/public
ln -s /home/doms/www.example.org/rails/public htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/www.example.org/fastcgi-ssl/ und ~/doms/www.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-09-02T18:33:44Z

Srv00-wiki: /* Konfiguration von FastCGI */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und diese mit einer sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/www.example.org/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/www.example.org/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=www.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/www.example.org/rails, oder erstellt dort eine Neue (rails ~/doms/www.example.org/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/www.example.org/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: www.example.org
attachments_storage_path: /home/doms/www.example.org/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/www.example.org/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/www.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/www.example.org/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/www.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/www.example.org/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'

Die Applikation ins Webroot einbinden:

cd ~/doms/www.example.org
# ggf. vorhandene Dateien sichern (oder nach ~/doms/www.example.org/rails/public kopieren),
mv htdocs htdocs.old
# und das entsprechende public/ Verzeichnis der Rails-Anwendung im Webroot verlinken.
# Standardmäsig /home/doms/www.example.org/rails/public,
# bei multi-site Anwendungen wie zena aber z.B. /home/doms/www.example.org/rails/site/www.example.org/public
ln -s /home/doms/www.example.org/rails/public htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/www.example.org/fastcgi-ssl/ und ~/doms/www.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-09-02T18:30:51Z

Srv00-wiki: /* Konfiguration von FastCGI */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und diese mit einer sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/www.example.org/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/www.example.org/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=www.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/www.example.org/rails, oder erstellt dort eine Neue (rails ~/doms/www.example.org/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/www.example.org/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: www.example.org
attachments_storage_path: /home/doms/www.example.org/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/www.example.org/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/www.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/www.example.org/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/www.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/www.example.org/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'

Die Applikation ins Webroot einbinden:

cd ~/doms/www.example.org
# ggf. vorhandene Dateien sichern (oder nach ~/doms/www.example.org/rails/public kopieren)
mv htdocs htdocs.old
# Das public/ Verzeichnis der Rails-Anwendung ins Webroot verlinken.
# Standardmäsig /home/doms/www.example.org/rails/public,
# bei multi-site Anwendungen wie zena aber z.B. /home/doms/www.example.org/rails/site/www.example.org/public
ln -s /home/doms/www.example.org/rails/public htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/www.example.org/fastcgi-ssl/ und ~/doms/www.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

MySQL

2012-09-02T18:14:02Z

Srv00-wiki: /* Weitere Benutzer anlegen */

== Server ==

Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen localhost und den Port 3306 (default). Außerdem kann der Server über den Socket /var/run/mysqld/mysqld.sock erreicht werden.

Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist ist durch die
Anzahl der jeweils gebuchten Multioptionen begrenzt. Der damit verbrauchte Speicherplatz geht in die Quota des Paketes mit ein, sodass hierüber eine zusätzliche Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. xyz00_datenbank.

== MySQL-User ==

{{Textkasten|gruen||Die Namen der Datenbank-Benutzer müssen in keiner Beziehung zu den Unix-Benutzernamen auf den Hostsharing-Systemen stehen, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}

Es gilt jedoch die Regel, dass die Namen aller Datenbank-Benutzer eines Pakets mit dem Paketkürzel beginnen. Eine sinnvolle Konvention ist es, sofern man als Paketadministrator einen zentralen Datenbank-Administrator für alle Datenbanken einrichten möchte, diesen nur nach dem Paket zu benennen (z. B. '''xyz00'''). So zeigt der kurze Name die Sonderstellung an und der Paket-Administrator gleichzeitig zentraler Datenbankadministrator ist, kann er seinen Datenbank-Benutzernamen nicht ohne den Paket-Namen vergessen, sprich immer leicht ableiten.

Weitere Datenbank-Benutzernamen können aus dem Paket-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Unix-User-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').

Sinnvoll ist es z.B. für jede Anwendung eine eigene Datenbank und mindestens einen auf die jeweilige Datenbank beschränkten Benutzer anzulegen.

=== Paketadmin ===

Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:

* Datenbanken anlegen und löschen
* Datenbank-Benutzer anlegen und löschen

Bevor man in seinem Paket eine Datenbank anlegen kann, muss man zunächst einen Datenbank-Benutzer einrichten, den man zum Datenbank-Administrator machen kann. Das ist zwingend notwendig. Datenbank-Administrator kann ein Datenbank-User mit dem Kürzel des Paketadmins sein (xyz00). Es können allerdings auch beliebige Namen, die mit dem Paketkürzel xyz00_... beginnen angelegt werden. Ein Datenbank-Adminstrator hat alle Rechte an einer Datenbank und wird wie unter "[[Datenbanken#Verwaltung_von_Datenbanken |Verwaltung von Datenbanken]]" beschrieben eingerichtet.

=== Weitere Benutzer anlegen ===

Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang eines Datenbank-Admins nur für administrative Zwecke zu benutzen. Wenn Skripte z.B. keine ganzen Tabellen löschen dürfen (drop) kann dies auch nicht aus versehen oder böswillig geschehen. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Leserechte an bestimmten Tabellen oder bestimmte Kommandos.

Wir legen noch einen User an:

siehe [[Datenbanken]]

=== Der MySQL-Monitor ===

Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl mysql aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen - auch auf den Paketadmin-Account.

Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.

<pre><nowiki>
xyz00@hopi$ mysql -u xyz00 -p
Enter password: password
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1257230 to server version: 3.23.49-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
</nowiki></pre>

Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Monitor wieder verlässt.
=== Datenbank anlegen ===

geht nun auch mit [[hsadmin]] siehe [[Datenbanken]].

Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.

Beispiele gültiger Datenbanken für ein Paket xyz00:
* xyz00_otto
* xyz00_anna
* xyz00_db_fuer_hans

=== Rechte vergeben ===

Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl GRANT.

<pre><nowiki>
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;
</nowiki></pre>

Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren.

Mit GRANT ALL kann man einem User auch alle Kommandorechte zuweisen.

Alle Aufgaben können wir jetzt in Zukunft vom User xyz00_otto erledigen lassen.

== Verschiedenes ==

* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Datenbanken]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

MySQL

2012-09-02T18:13:20Z

Srv00-wiki: /* MySQL-User */

== Server ==

Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen localhost und den Port 3306 (default). Außerdem kann der Server über den Socket /var/run/mysqld/mysqld.sock erreicht werden.

Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist ist durch die
Anzahl der jeweils gebuchten Multioptionen begrenzt. Der damit verbrauchte Speicherplatz geht in die Quota des Paketes mit ein, sodass hierüber eine zusätzliche Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. xyz00_datenbank.

== MySQL-User ==

{{Textkasten|gruen||Die Namen der Datenbank-Benutzer müssen in keiner Beziehung zu den Unix-Benutzernamen auf den Hostsharing-Systemen stehen, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}

Es gilt jedoch die Regel, dass die Namen aller Datenbank-Benutzer eines Pakets mit dem Paketkürzel beginnen. Eine sinnvolle Konvention ist es, sofern man als Paketadministrator einen zentralen Datenbank-Administrator für alle Datenbanken einrichten möchte, diesen nur nach dem Paket zu benennen (z. B. '''xyz00'''). So zeigt der kurze Name die Sonderstellung an und der Paket-Administrator gleichzeitig zentraler Datenbankadministrator ist, kann er seinen Datenbank-Benutzernamen nicht ohne den Paket-Namen vergessen, sprich immer leicht ableiten.

Weitere Datenbank-Benutzernamen können aus dem Paket-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Unix-User-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').

Sinnvoll ist es z.B. für jede Anwendung eine eigene Datenbank und mindestens einen auf die jeweilige Datenbank beschränkten Benutzer anzulegen.

=== Paketadmin ===

Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:

* Datenbanken anlegen und löschen
* Datenbank-Benutzer anlegen und löschen

Bevor man in seinem Paket eine Datenbank anlegen kann, muss man zunächst einen Datenbank-Benutzer einrichten, den man zum Datenbank-Administrator machen kann. Das ist zwingend notwendig. Datenbank-Administrator kann ein Datenbank-User mit dem Kürzel des Paketadmins sein (xyz00). Es können allerdings auch beliebige Namen, die mit dem Paketkürzel xyz00_... beginnen angelegt werden. Ein Datenbank-Adminstrator hat alle Rechte an einer Datenbank und wird wie unter "[[Datenbanken#Verwaltung_von_Datenbanken |Verwaltung von Datenbanken]]" beschrieben eingerichtet.

=== Weitere Benutzer anlegen ===

Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang eines Datenbank-Admins nur für administrative Zwecke zu benutzen. Wenn Skripten z.B. keine ganzen Tabellen löschen dürfen (drop) kann dies auch nicht aus versehen oder böswillig geschehen. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Leserechte an bestimmten Tabellen oder bestimmte Kommandos.

Wir legen noch einen User an:

siehe [[Datenbanken]]

=== Der MySQL-Monitor ===

Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl mysql aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen - auch auf den Paketadmin-Account.

Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.

<pre><nowiki>
xyz00@hopi$ mysql -u xyz00 -p
Enter password: password
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1257230 to server version: 3.23.49-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
</nowiki></pre>

Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Monitor wieder verlässt.
=== Datenbank anlegen ===

geht nun auch mit [[hsadmin]] siehe [[Datenbanken]].

Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.

Beispiele gültiger Datenbanken für ein Paket xyz00:
* xyz00_otto
* xyz00_anna
* xyz00_db_fuer_hans

=== Rechte vergeben ===

Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl GRANT.

<pre><nowiki>
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;
</nowiki></pre>

Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren.

Mit GRANT ALL kann man einem User auch alle Kommandorechte zuweisen.

Alle Aufgaben können wir jetzt in Zukunft vom User xyz00_otto erledigen lassen.

== Verschiedenes ==

* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Datenbanken]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

RubyOnRails

2012-09-02T18:07:45Z

Srv00-wiki:

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und diese mit einer sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/www.example.org/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/www.example.org/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=www.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/www.example.org/rails, oder erstellt dort eine Neue (rails ~/doms/www.example.org/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/www.example.org/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: www.example.org
attachments_storage_path: /home/doms/www.example.org/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/www.example.org/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/www.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/www.example.org/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/www.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/www.example.org/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/doms/www.example.org/rails/public kopieren)
mv ~/doms/www.example.org/htdocs ~/doms/www.example.org/htdocs.old
# Das doms/www.example.org/rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/doms/www..com/rails/public ~/doms/www.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/www.example.org/fastcgi-ssl/ und ~/doms/www.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-09-02T17:59:51Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und diese mit einer sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/example.com/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/example.com/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/example.com/rails, oder erstellt dort eine Neue (rails ~/doms/example.com/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/example.com/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/doms/example.com/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/example.com/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/example.com/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/example.com/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/doms/example.com/rails/public kopieren)
mv ~/doms/example.org/htdocs ~/doms/example.org/htdocs.old
# Das doms/example.com/rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/doms/example.com/rails/public ~/doms/example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-09-02T17:56:23Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine fertige CMS Anwendung installiert (http://zenadmin.org) und mit einer einfachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/example.com/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/example.com/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/example.com/rails, oder erstellt dort eine Neue (rails ~/doms/example.com/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/example.com/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/doms/example.com/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/example.com/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/example.com/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/example.com/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/doms/example.com/rails/public kopieren)
mv ~/doms/example.org/htdocs ~/doms/example.org/htdocs.old
# Das doms/example.com/rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/doms/example.com/rails/public ~/doms/example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-09-02T17:55:32Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine fertige CMS Anwendung installiert (http://zenadmin.org) und mit einer einfachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/example.com/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/example.com/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/example.com/rails, oder erstellt dort eine Neue (rails ~/doms/example.com/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/example.com/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/doms/example.com/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/example.com/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/example.com/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/example.com/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/doms/example.com/rails/public kopieren)
mv ~/doms/example.org/htdocs ~/doms/example.org/htdocs.old
# Das doms/example.com/rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/doms/example.com/rails/public ~/doms/example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-09-02T17:52:28Z

Srv00-wiki: /* E-Mail, Dateiablage */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine fertige CMS Anwendung installiert (http://zenadmin.org) und mit einer einfachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/example.com/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/example.com/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/example.com/rails, oder erstellt dort eine Neue (rails ~/doms/example.com/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/example.com/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/doms/example.com/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/example.com/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/example.com/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/example.com/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/doms/example.com/rails/public kopieren)
mv ~/doms/example.org/htdocs ~/doms/example.org/htdocs.old
# Das doms/example.com/rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/doms/example.com/rails/public ~/doms/example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-09-02T17:51:40Z

Srv00-wiki: /* Konfiguration von FastCGI */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine fertige CMS Anwendung installiert (http://zenadmin.org) und mit einer einfachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/example.com/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/example.com/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/example.com/rails, oder erstellt dort eine Neue (rails ~/doms/example.com/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/example.com/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/doms/example.com/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/example.com/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/example.com/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/example.com/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/doms/example.com/rails/public kopieren)
mv ~/doms/example.org/htdocs ~/doms/example.org/htdocs.old
# Das doms/example.com/rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/doms/example.com/rails/public ~/doms/example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-09-02T17:07:10Z

Srv00-wiki:

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine fertige CMS Anwendung installiert (http://zenadmin.org) und mit einer einfachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/example.com/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/example.com/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/example.com/rails, oder erstellt dort eine Neue (rails ~/doms/example.com/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/example.com/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/doms/example.com/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/example.com/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/doms/example.com/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/example.com/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/doms/example.com/rails/public kopieren)
mv ~/doms/example.org/htdocs ~/doms/example.org/htdocs.old
# Das doms/example.com/rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/doms/example.com/rails/public ~/doms/example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

MySQL

2012-09-02T16:53:36Z

Srv00-wiki:

== Server ==

Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen localhost und den Port 3306 (default). Außerdem kann der Server über den Socket /var/run/mysqld/mysqld.sock erreicht werden.

Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist ist durch die
Anzahl der jeweils gebuchten Multioptionen begrenzt. Der damit verbrauchte Speicherplatz geht in die Quota des Paketes mit ein, sodass hierüber eine zusätzliche Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. xyz00_datenbank.

== MySQL-User ==

{{Textkasten|gruen||Die Namen der Datenbank-Benutzer müssen in keiner Beziehung zu den Unix-Benutzernamen auf den Hostsharing-Systemen stehen, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}

Es gilt jedoch die Regel, dass die Namen aller Datenbank-Benutzer eines Pakets mit dem Paketkürzel beginnen. Eine sinnvolle Konvention ist es, sofern man als Paketadministrator einen zentralen Datenbank-Administrator für alle Datenbanken einrichten möchte, diesen nur nach dem Paket zu benennen (z. B. '''xyz00'''). So zeigt der kurze Name die Sonderstellung an und der Paket-Administrator gleichzeitig zentraler Datenbankadministrator ist, kann er seinen Datenbank-Benutzernamen nicht ohne den Paket-Namen vergessen, sprich immer leicht ableiten.

Weitere Datenbank-Benutzernamen können aus dem Paket-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Unix-User-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').

Sinnvoll ist es z.B. für jede Anwendung eine eigene Datenbank und mindestens einen auf jeweilige Datenbank beschränkten Benutzer anzulegen.

=== Paketadmin ===

Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:

* Datenbanken anlegen und löschen
* Datenbank-Benutzer anlegen und löschen

Bevor man in seinem Paket eine Datenbank anlegen kann, muss man zunächst einen Datenbank-Benutzer einrichten, den man zum Datenbank-Administrator machen kann. Das ist zwingend notwendig. Datenbank-Administrator kann ein Datenbank-User mit dem Kürzel des Paketadmins sein (xyz00). Es können allerdings auch beliebige Namen, die mit dem Paketkürzel xyz00_... beginnen angelegt werden. Ein Datenbank-Adminstrator hat alle Rechte an einer Datenbank und wird wie unter "[[Datenbanken#Verwaltung_von_Datenbanken |Verwaltung von Datenbanken]]" beschrieben eingerichtet.

=== Weitere Benutzer anlegen ===

Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang eines Datenbank-Admins nur für administrative Zwecke zu benutzen. Wenn Skripten z.B. keine ganzen Tabellen löschen dürfen (drop) kann dies auch nicht aus versehen oder böswillig geschehen. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Leserechte an bestimmten Tabellen oder bestimmte Kommandos.

Wir legen noch einen User an:

siehe [[Datenbanken]]

=== Der MySQL-Monitor ===

Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl mysql aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen - auch auf den Paketadmin-Account.

Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.

<pre><nowiki>
xyz00@hopi$ mysql -u xyz00 -p
Enter password: password
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1257230 to server version: 3.23.49-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
</nowiki></pre>

Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Monitor wieder verlässt.
=== Datenbank anlegen ===

geht nun auch mit [[hsadmin]] siehe [[Datenbanken]].

Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.

Beispiele gültiger Datenbanken für ein Paket xyz00:
* xyz00_otto
* xyz00_anna
* xyz00_db_fuer_hans

=== Rechte vergeben ===

Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl GRANT.

<pre><nowiki>
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;
</nowiki></pre>

Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren.

Mit GRANT ALL kann man einem User auch alle Kommandorechte zuweisen.

Alle Aufgaben können wir jetzt in Zukunft vom User xyz00_otto erledigen lassen.

== Verschiedenes ==

* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Datenbanken]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

RubyOnRails

2012-09-02T16:38:08Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine fertige CMS Anwendung installiert (http://zenadmin.org) und mit einer einfachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

MySQL

2012-09-01T22:51:31Z

Srv00-wiki: /* MySQL-User */

== Server ==

Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen localhost und den Port 3306 (default). Außerdem kann der Server über den Socket /var/run/mysqld/mysqld.sock erreicht werden.

Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist ist durch die
Anzahl der jeweils gebuchten Multioptionen begrenzt. Der damit verbrauchte Speicherplatz geht in die Quota des Paketes mit ein, sodass hierüber eine zusätzliche Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. xyz00_datenbank.

== MySQL-User ==

{{Textkasten|gruen||Die Namen der Datenbank-Benutzer müssen in keiner Beziehung zu den Unix-Benutzernamen auf den Hostsharing-Systemen stehen, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}

Es gilt jedoch die Regel, dass die Namen aller Datenbank-Benutzer eines Pakets mit dem Paketkürzel beginnen. Eine sinnvolle Konvention ist es, sofern man als Paketadministrator einen zentralen Datenbank-Administrator für alle Datenbanken einrichten möchte, diesen nur nach dem Paket zu benennen (z. B. '''xyz00'''). So zeigt der kurze Name die Sonderstellung an und der Paket-Administrator gleichzeitig zentraler Datenbankadministrator ist, kann er seinen Datenbank-Benutzernamen nicht ohne den Paket-Namen vergessen, sprich immer leicht ableiten.

Weitere Datenbank-Benutzernamen können aus dem Paket-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Unix-User-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').

=== Paketadmin ===

Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:

* Datenbanken anlegen und löschen
* Datenbank-Benutzer anlegen und löschen

Bevor man in seinem Paket eine Datenbank anlegen kann, muss man zunächst einen Datenbank-Benutzer einrichten, den man zum Datenbank-Administrator machen kann. Das ist zwingend notwendig. Datenbank-Administrator kann ein Datenbank-User mit dem Kürzel des Paketadmins sein (xyz00). Es können allerdings auch beliebige Namen, die mit dem Paketkürzel xyz00_... beginnen angelegt werden. Ein Datenbank-Adminstrator hat alle Rechte an einer Datenbank und wird wie unter "[[Datenbanken#Verwaltung_von_Datenbanken |Verwaltung von Datenbanken]]" beschrieben eingerichtet.

=== Weitere Benutzer anlegen ===

Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang eines Datenbank-Admins nur für administrative Zwecke zu benutzen. Schließlich will man nicht immer den mächtigen Account des Paketadmins in seinen Skripten verwenden. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Rechte an bestimmten Tabellen oder zur Ausführung bestimmter Kommandos.

Wir legen noch einen User an:

siehe [[Datenbanken]]

=== Der MySQL-Monitor ===

Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl mysql aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen - auch auf den Paketadmin-Account.

Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.

<pre><nowiki>
xyz00@hopi$ mysql -u xyz00 -p
Enter password: password
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1257230 to server version: 3.23.49-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
</nowiki></pre>

Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Monitor wieder verlässt.
=== Datenbank anlegen ===

geht nun auch mit [[hsadmin]] siehe [[Datenbanken]].

Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.

Beispiele gültiger Datenbanken für ein Paket xyz00:
* xyz00_otto
* xyz00_anna
* xyz00_db_fuer_hans

=== Rechte vergeben ===

Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl GRANT.

<pre><nowiki>
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;
</nowiki></pre>

Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren.

Mit GRANT ALL kann man einem User auch alle Kommandorechte zuweisen.

Alle Aufgaben können wir jetzt in Zukunft vom User xyz00_otto erledigen lassen.

== Verschiedenes ==

* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Datenbanken]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

MySQL

2012-09-01T22:49:14Z

Srv00-wiki: /* MySQL-User */

== Server ==

Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen localhost und den Port 3306 (default). Außerdem kann der Server über den Socket /var/run/mysqld/mysqld.sock erreicht werden.

Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist ist durch die
Anzahl der jeweils gebuchten Multioptionen begrenzt. Der damit verbrauchte Speicherplatz geht in die Quota des Paketes mit ein, sodass hierüber eine zusätzliche Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. xyz00_datenbank.

== MySQL-User ==

{{Textkasten|gruen||Die Namen der Datenbank-Benutzer müssen in keiner Beziehung zu den Unix-Benutzernamen der Hostsharing-Systeme stehen, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}

Es gilt jedoch die Regel, dass die Namen aller Datenbank-Benutzer eines Pakets mit dem Paketkürzel beginnen. Eine sinnvolle Konvention ist es, sofern man als Paketadministrator einen zentralen Datenbank-Administrator für alle Datenbanken einrichten möchte, diesen nur nach dem Paket zu benennen (z. B. '''xyz00'''). So zeigt der kurze Name die Sonderstellung an und der Paket-Administrator gleichzeitig zentraler Datenbankadministrator ist, kann er seinen Datenbank-Benutzernamen nicht ohne den Paket-Namen vergessen, sprich immer leicht ableiten.

Weitere Datenbank-Benutzernamen können aus dem Paket-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Unix-User-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').

=== Paketadmin ===

Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:

* Datenbanken anlegen und löschen
* Datenbank-Benutzer anlegen und löschen

Bevor man in seinem Paket eine Datenbank anlegen kann, muss man zunächst einen Datenbank-Benutzer einrichten, den man zum Datenbank-Administrator machen kann. Das ist zwingend notwendig. Datenbank-Administrator kann ein Datenbank-User mit dem Kürzel des Paketadmins sein (xyz00). Es können allerdings auch beliebige Namen, die mit dem Paketkürzel xyz00_... beginnen angelegt werden. Ein Datenbank-Adminstrator hat alle Rechte an einer Datenbank und wird wie unter "[[Datenbanken#Verwaltung_von_Datenbanken |Verwaltung von Datenbanken]]" beschrieben eingerichtet.

=== Weitere Benutzer anlegen ===

Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang eines Datenbank-Admins nur für administrative Zwecke zu benutzen. Schließlich will man nicht immer den mächtigen Account des Paketadmins in seinen Skripten verwenden. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Rechte an bestimmten Tabellen oder zur Ausführung bestimmter Kommandos.

Wir legen noch einen User an:

siehe [[Datenbanken]]

=== Der MySQL-Monitor ===

Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl mysql aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen - auch auf den Paketadmin-Account.

Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.

<pre><nowiki>
xyz00@hopi$ mysql -u xyz00 -p
Enter password: password
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1257230 to server version: 3.23.49-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
</nowiki></pre>

Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Monitor wieder verlässt.
=== Datenbank anlegen ===

geht nun auch mit [[hsadmin]] siehe [[Datenbanken]].

Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.

Beispiele gültiger Datenbanken für ein Paket xyz00:
* xyz00_otto
* xyz00_anna
* xyz00_db_fuer_hans

=== Rechte vergeben ===

Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl GRANT.

<pre><nowiki>
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;
</nowiki></pre>

Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren.

Mit GRANT ALL kann man einem User auch alle Kommandorechte zuweisen.

Alle Aufgaben können wir jetzt in Zukunft vom User xyz00_otto erledigen lassen.

== Verschiedenes ==

* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Datenbanken]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

MySQL

2012-09-01T22:47:06Z

Srv00-wiki: /* MySQL-User */

== Server ==

Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen localhost und den Port 3306 (default). Außerdem kann der Server über den Socket /var/run/mysqld/mysqld.sock erreicht werden.

Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist ist durch die
Anzahl der jeweils gebuchten Multioptionen begrenzt. Der damit verbrauchte Speicherplatz geht in die Quota des Paketes mit ein, sodass hierüber eine zusätzliche Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. xyz00_datenbank.

== MySQL-User ==

{{Textkasten|gruen||Die Namen der Datenbank-Benutzer müssen in keiner Beziehung zu den Unix-Benutzernamen der Hostsharing-Systeme stehen, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}

Es gilt jedoch die Regel, dass die Namen aller Datenbank-Benutzer eines Pakets mit dem Paketkürzel beginnen. Eine sinnvolle Konvention ist es, sofern man als Paketadministrator einen zentralen Datenbank-Administrator für alle Datenbanken einrichten möchte, diesen nur nach dem Paket zu benennen (z. B. '''xyz00'''). So zeigt der kurze Name die Sonderstellung an und der Paket-Administrator gleichzeitig zentraler Datenbankadministrator ist, kann er seinen Datenbank-Benutzernamen nicht ohne den Paket-Namen vergessen, sprich immer leicht ableiten.

Weitere Datenbank-Benutzernamen können aus dem Paket-Admin-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Domain-Admin-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').

=== Paketadmin ===

Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:

* Datenbanken anlegen und löschen
* Datenbank-Benutzer anlegen und löschen

Bevor man in seinem Paket eine Datenbank anlegen kann, muss man zunächst einen Datenbank-Benutzer einrichten, den man zum Datenbank-Administrator machen kann. Das ist zwingend notwendig. Datenbank-Administrator kann ein Datenbank-User mit dem Kürzel des Paketadmins sein (xyz00). Es können allerdings auch beliebige Namen, die mit dem Paketkürzel xyz00_... beginnen angelegt werden. Ein Datenbank-Adminstrator hat alle Rechte an einer Datenbank und wird wie unter "[[Datenbanken#Verwaltung_von_Datenbanken |Verwaltung von Datenbanken]]" beschrieben eingerichtet.

=== Weitere Benutzer anlegen ===

Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang eines Datenbank-Admins nur für administrative Zwecke zu benutzen. Schließlich will man nicht immer den mächtigen Account des Paketadmins in seinen Skripten verwenden. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Rechte an bestimmten Tabellen oder zur Ausführung bestimmter Kommandos.

Wir legen noch einen User an:

siehe [[Datenbanken]]

=== Der MySQL-Monitor ===

Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl mysql aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen - auch auf den Paketadmin-Account.

Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.

<pre><nowiki>
xyz00@hopi$ mysql -u xyz00 -p
Enter password: password
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1257230 to server version: 3.23.49-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
</nowiki></pre>

Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Monitor wieder verlässt.
=== Datenbank anlegen ===

geht nun auch mit [[hsadmin]] siehe [[Datenbanken]].

Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.

Beispiele gültiger Datenbanken für ein Paket xyz00:
* xyz00_otto
* xyz00_anna
* xyz00_db_fuer_hans

=== Rechte vergeben ===

Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl GRANT.

<pre><nowiki>
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;
</nowiki></pre>

Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren.

Mit GRANT ALL kann man einem User auch alle Kommandorechte zuweisen.

Alle Aufgaben können wir jetzt in Zukunft vom User xyz00_otto erledigen lassen.

== Verschiedenes ==

* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Datenbanken]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

MySQL

2012-09-01T22:40:48Z

Srv00-wiki: /* Weitere Benutzer anlegen */

== Server ==

Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen localhost und den Port 3306 (default). Außerdem kann der Server über den Socket /var/run/mysqld/mysqld.sock erreicht werden.

Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist ist durch die
Anzahl der jeweils gebuchten Multioptionen begrenzt. Der damit verbrauchte Speicherplatz geht in die Quota des Paketes mit ein, sodass hierüber eine zusätzliche Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. xyz00_datenbank.

== MySQL-User ==

{{Textkasten|gruen||Die Namen der Datenbank-Benutzer müssen in keiner Beziehung zu den Unix-Benutzernamen der Hostsharing-Systeme stehen, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}

Es gilt jedoch die Regel, dass die Namen aller Datenbank-Benutzer eines Pakets mit dem Paketkürzel beginnen. Eine sinnvolle Konvention ist es, sofern man als Paketadministrator einen zentralen Datenbank-Administrator für alle Datenbanken einrichten möchte, diesen nur nach dem Paket zu benennen (z. B. '''xyz00'''). So kann der Paket-Admin seinen Benutzernamen für den Datenbank-Zugang nicht vergessen.

Weitere Datenbank-Benutzernamen können aus dem Paket-Admin-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Domain-Admin-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').

=== Paketadmin ===

Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:

* Datenbanken anlegen und löschen
* Datenbank-Benutzer anlegen und löschen

Bevor man in seinem Paket eine Datenbank anlegen kann, muss man zunächst einen Datenbank-Benutzer einrichten, den man zum Datenbank-Administrator machen kann. Das ist zwingend notwendig. Datenbank-Administrator kann ein Datenbank-User mit dem Kürzel des Paketadmins sein (xyz00). Es können allerdings auch beliebige Namen, die mit dem Paketkürzel xyz00_... beginnen angelegt werden. Ein Datenbank-Adminstrator hat alle Rechte an einer Datenbank und wird wie unter "[[Datenbanken#Verwaltung_von_Datenbanken |Verwaltung von Datenbanken]]" beschrieben eingerichtet.

=== Weitere Benutzer anlegen ===

Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang eines Datenbank-Admins nur für administrative Zwecke zu benutzen. Schließlich will man nicht immer den mächtigen Account des Paketadmins in seinen Skripten verwenden. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Rechte an bestimmten Tabellen oder zur Ausführung bestimmter Kommandos.

Wir legen noch einen User an:

siehe [[Datenbanken]]

=== Der MySQL-Monitor ===

Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl mysql aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen - auch auf den Paketadmin-Account.

Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.

<pre><nowiki>
xyz00@hopi$ mysql -u xyz00 -p
Enter password: password
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1257230 to server version: 3.23.49-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
</nowiki></pre>

Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Monitor wieder verlässt.
=== Datenbank anlegen ===

geht nun auch mit [[hsadmin]] siehe [[Datenbanken]].

Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.

Beispiele gültiger Datenbanken für ein Paket xyz00:
* xyz00_otto
* xyz00_anna
* xyz00_db_fuer_hans

=== Rechte vergeben ===

Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl GRANT.

<pre><nowiki>
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;
</nowiki></pre>

Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren.

Mit GRANT ALL kann man einem User auch alle Kommandorechte zuweisen.

Alle Aufgaben können wir jetzt in Zukunft vom User xyz00_otto erledigen lassen.

== Verschiedenes ==

* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Datenbanken]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

MySQL

2012-09-01T22:39:06Z

Srv00-wiki: /* Paketadmin */

== Server ==

Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen localhost und den Port 3306 (default). Außerdem kann der Server über den Socket /var/run/mysqld/mysqld.sock erreicht werden.

Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist ist durch die
Anzahl der jeweils gebuchten Multioptionen begrenzt. Der damit verbrauchte Speicherplatz geht in die Quota des Paketes mit ein, sodass hierüber eine zusätzliche Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. xyz00_datenbank.

== MySQL-User ==

{{Textkasten|gruen||Die Namen der Datenbank-Benutzer müssen in keiner Beziehung zu den Unix-Benutzernamen der Hostsharing-Systeme stehen, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}

Es gilt jedoch die Regel, dass die Namen aller Datenbank-Benutzer eines Pakets mit dem Paketkürzel beginnen. Eine sinnvolle Konvention ist es, sofern man als Paketadministrator einen zentralen Datenbank-Administrator für alle Datenbanken einrichten möchte, diesen nur nach dem Paket zu benennen (z. B. '''xyz00'''). So kann der Paket-Admin seinen Benutzernamen für den Datenbank-Zugang nicht vergessen.

Weitere Datenbank-Benutzernamen können aus dem Paket-Admin-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Domain-Admin-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').

=== Paketadmin ===

Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:

* Datenbanken anlegen und löschen
* Datenbank-Benutzer anlegen und löschen

Bevor man in seinem Paket eine Datenbank anlegen kann, muss man zunächst einen Datenbank-Benutzer einrichten, den man zum Datenbank-Administrator machen kann. Das ist zwingend notwendig. Datenbank-Administrator kann ein Datenbank-User mit dem Kürzel des Paketadmins sein (xyz00). Es können allerdings auch beliebige Namen, die mit dem Paketkürzel xyz00_... beginnen angelegt werden. Ein Datenbank-Adminstrator hat alle Rechte an einer Datenbank und wird wie unter "[[Datenbanken#Verwaltung_von_Datenbanken |Verwaltung von Datenbanken]]" beschrieben eingerichtet.

=== Weitere Benutzer anlegen ===

Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang des Paketadmins nur für administrative Zwecke zu benutzen. Schließlich will man nicht immer den mächtigen Account des Paketadmins in seinen Skripten verwenden. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Rechte an bestimmten Datenbanken oder zur Ausführung bestimmter Kommandos.

Wir legen noch einen User an:

siehe [[Datenbanken]]

=== Der MySQL-Monitor ===

Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl mysql aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen - auch auf den Paketadmin-Account.

Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.

<pre><nowiki>
xyz00@hopi$ mysql -u xyz00 -p
Enter password: password
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1257230 to server version: 3.23.49-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
</nowiki></pre>

Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Monitor wieder verlässt.
=== Datenbank anlegen ===

geht nun auch mit [[hsadmin]] siehe [[Datenbanken]].

Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.

Beispiele gültiger Datenbanken für ein Paket xyz00:
* xyz00_otto
* xyz00_anna
* xyz00_db_fuer_hans

=== Rechte vergeben ===

Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl GRANT.

<pre><nowiki>
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;
</nowiki></pre>

Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren.

Mit GRANT ALL kann man einem User auch alle Kommandorechte zuweisen.

Alle Aufgaben können wir jetzt in Zukunft vom User xyz00_otto erledigen lassen.

== Verschiedenes ==

* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Datenbanken]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

MySQL

2012-09-01T22:34:45Z

Srv00-wiki:

== Server ==

Wir haben pro Host einen einzelnen MySQL Datenbankserver. Der Zugriff erfolgt über den Hostnamen localhost und den Port 3306 (default). Außerdem kann der Server über den Socket /var/run/mysqld/mysqld.sock erreicht werden.

Die Anzahl der in Hostsharing Dynamic-Web-Paketen verwendbaren MySQL-Datenbanken ist ist durch die
Anzahl der jeweils gebuchten Multioptionen begrenzt. Der damit verbrauchte Speicherplatz geht in die Quota des Paketes mit ein, sodass hierüber eine zusätzliche Begrenzung vorliegt. Alle Datenbanken eines Paketes müssen mit dem Paketnamen und einem Underscore beginnen, also z.B. xyz00_datenbank.

== MySQL-User ==

{{Textkasten|gruen||Die Namen der Datenbank-Benutzer müssen in keiner Beziehung zu den Unix-Benutzernamen der Hostsharing-Systeme stehen, also den Namen, die für den [[shell]]-Zugang verwendet werden.}}

Es gilt jedoch die Regel, dass die Namen aller Datenbank-Benutzer eines Pakets mit dem Paketkürzel beginnen. Eine sinnvolle Konvention ist es, sofern man als Paketadministrator einen zentralen Datenbank-Administrator für alle Datenbanken einrichten möchte, diesen nur nach dem Paket zu benennen (z. B. '''xyz00'''). So kann der Paket-Admin seinen Benutzernamen für den Datenbank-Zugang nicht vergessen.

Weitere Datenbank-Benutzernamen können aus dem Paket-Admin-Namen, einem Unterstrich, und einer freien Zeichenfolge gebildet werden. Also kann der Paketadmin '''xyz00''' weitere User der Form '''xyz00_abc''' einrichten. Beachte die Differenz zu Domain-Admin-Namen, die nicht mit Unterstrich, sondern mit Bindestrich gebildet werden ('''xyz00''' -> '''xyz00-abc''').

=== Paketadmin ===

Der Paketadmin hat mit seinem Account sehr weitgehende administrative Rechte in MySQL und sollte dementsprechend mit Umsicht genutzt werden. Er kann mit seinem Account im Administrationswerkzeug [[hsadmin]] unter anderem:

* Datenbanken anlegen und löschen
* Datenbank-Benutzer anlegen und löschen

Bevor man in seinem Paket eine Datenbank anlegen kann, muss man zunächst einen Datenbank-Benutzer einrichten, den man zum Datenbank-Administrator machen kann. Das ist zwingend notwendig. Es kann ein Datenbank-User mit dem Kürzel des Paketadmins (xyz00) sein. Es können allerdings auch beliebige Namen, die mit dem Paketkürzel xyz00_... beginnen angelegt werden. Ein Datenbank-Adminstrator wird eingerichtet, wie unter "[[Datenbanken#Verwaltung_von_Datenbanken |Verwaltung von Datenbanken]]" beschrieben ist.

=== Weitere Benutzer anlegen ===

Du kannst Dir weitere Benutzer für MySQL anlegen. Wir empfehlen Dir das ausdrücklich, weil es eine gute Idee ist, den mächtigen Zugang des Paketadmins nur für administrative Zwecke zu benutzen. Schließlich will man nicht immer den mächtigen Account des Paketadmins in seinen Skripten verwenden. Für einzelne Aufgaben kannst Du verschiedene Benutzer anlegen, denen Du natürlich auch verschiedene Rechte geben kannst, z.B. nur Rechte an bestimmten Datenbanken oder zur Ausführung bestimmter Kommandos.

Wir legen noch einen User an:

siehe [[Datenbanken]]

=== Der MySQL-Monitor ===

Mit den neu angelegten User-Accounts können wir nun in den MySQL-Monitor wechseln, in dem die MySQL-Befehle eingegeben und verarbeitet werden. Der Monitor wird mit dem Befehl mysql aufgerufen. Es ist hier übrigens egal, ob wir als Paketadmin oder als Domainadmin eingeloggt sind, denn MySQL-User und UNIX-Accounts haben keinen Zusammenhang. Wir können mit jedem UNIX-Account, also auch als normaler Domainadmin auf jeden Datenbank-Account zugreifen - auch auf den Paketadmin-Account.

Da wir uns mit Benutzernamen und Passwort anmelden müssen, verwenden wir die Optionen -u (und danach den Benutzernamen) und -p. Das Passwort geben wir nicht in dieser Kommandozeile an, denn sonst ist es für andere User sichtbar. Wenn wir nach -p nichts angeben, werden wir von mysql danach gefragt und geben es dann an.

<pre><nowiki>
xyz00@hopi$ mysql -u xyz00 -p
Enter password: password
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1257230 to server version: 3.23.49-log
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
</nowiki></pre>

Nun können wir MySQL-Befehle eingeben. Zu beachten ist, dass man nach einem Kommando mit einem ; abschließen muss. Es gibt einige Ausnahmen, wo man das nicht braucht, z.B. beim Befehl QUIT, mit dem man den Monitor wieder verlässt.
=== Datenbank anlegen ===

geht nun auch mit [[hsadmin]] siehe [[Datenbanken]].

Datenbanknamen in MySQL beginnen bei Hostsharing immer mit dem Namen des Pakets, gefolgt von einem Unterstrich; danach folgt der frei wählbare eigentliche Name.

Beispiele gültiger Datenbanken für ein Paket xyz00:
* xyz00_otto
* xyz00_anna
* xyz00_db_fuer_hans

=== Rechte vergeben ===

Allen Benutzern, außer dem Paketadmin, müssen wir noch Rechte geben, sonst können sie gar nichts machen. Das erledigt man mit dem Befehl GRANT.

<pre><nowiki>
mysql>GRANT SELECT, INSERT, DELETE, UPDATE ON xyz00_meinedatenbank.* TO xyz00_otto;
</nowiki></pre>

Hinter der Datenbank verwenden wir .*, um alle Tabellen der Datenbank zu inkludieren.

Mit GRANT ALL kann man einem User auch alle Kommandorechte zuweisen.

Alle Aufgaben können wir jetzt in Zukunft vom User xyz00_otto erledigen lassen.

== Verschiedenes ==

* Web-Frontend: [http://www.phpmyadmin.net phpMyAdmin] ist unter https://phpmyadmin.hostsharing.net/current erreichbar.
* Online-Dokumentation: Die Online-Doku zu MySQL gibt es unter http://dev.mysql.com/doc/. Auf dieser Site gibt es auch mehrere Fassungen der kompletten Doku zum Downloaden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Datenbanken]]
[[Kategorie:Glossar]]
[[Kategorie:ToDo-Kerndoku]]

Apache installieren

2012-08-31T22:05:26Z

Srv00-wiki:

__TOC__

Der [http://httpd.apache.org/ Apache] ist ein Webserver zur Beantwortung von HTTP-Requests und wird üblicherweise zur Auslieferung von Webseiten genutzt. Auf HS Systemen läuft ein zentraler Apache, der standardmäßig die Anfragen für die in den Paketen aufgeschalteten Domains verarbeitet und die Webseiten ausliefert.

Unter Umständen kann es sinnvoll sein, einen eigenen Apache zu betreiben, vor allem dann, wenn man Apache Module betreiben möchte, die vom zentralen Apache (z.B. aus Sicherheitsgründen im Shared Hosting) nicht zur Verfügung gestellt werden.

Es gibt zwei Möglichkeiten, einen eigenen Apache bei HS zu betreiben:

* '''Mit einer Portumleitung'''(Port Forwarding). Hierbei werden Requests auf die eigene IP:Port80 umgeleitet auf (z.B) Port 8080. Diese Option ist hier beschrieben.
* '''Hinter mod_proxy des zentralen Apaches'''. Dieser Betriebsmodus hat den Vorteil, pro Domain/Subdomain wählen zu können, ob man die Requests an den eigenen Apache delegiert. Es besteht somit die Möglichkeit weiterhin Domain-Admins zu verwenden und den eigenen Apache selektiv nur für den Service einzusetzen, für den man ihn braucht, während alle anderen Services durch den zentralen und betreuten Apache abgedeckt werden.

== Voraussetzungen ==

* '''eigene IP''': Eine eigene IP muss von den [[Hostmaster | Hostmastern]] eingerichet werden. Dies erfordert die kostenpflichtige Buchung der Option "eigener Apache".

== Konfiguration ~/etc/apache2.conf==

Die Konfiguration eines Apache kann hier nicht beschrieben werden, dafür gibt es ziemlich dicke Bücher. Nur ein paar Hinweise:

*Die Konfiguration des zentralen Apache kann in großen Teilen übernommen werden, man kann also gut /etc/apache2 in das eigene Benutzerverzeichnis ~/etc/apache2 kopieren, Pfade anpassen und einmal damit starten. Aber sei gewarnt: Den Apache (auch mit Vorwissen) zum Laufen zu bringen, braucht Wissen, Zeit und Geduld. Wer nicht ein Grundwissen in Linux-Administration mitbringt, sollte davon Abstand nehmen.

Hilfreich sind die Meldungen, die der Apache selbst in den Log-Dateien ausgibt und seine Möglichkeiten zu Überprüfung der Konfiguration. Hier der Configtest:

<pre>
xyz00@h00:~/etc/apache2$ /usr/sbin/apache2 -f /home/pacs/xyz00/etc/apache2/apache2.conf -t
Syntax OK
</pre>

Den sollte man unbedingt ausführen, bevor man eine geänderte Konfiguration durch Neustart des Apachen übernimmt.

=== Grundkonfiguration mit Portumleitung ===

*Voraussetzung: Portumleitungen '''Port 80 -> 8080''' und bei Bedarf '''443 -> 8443''' von einem [[Hostmaster]] eingerichtet.

Hier wird die eigene IP '''111.222.333.444''', und das HS-Paket '''xyz00''' angenommen, sowie, dass das Verzeichnis '''/home/pacs/xyz00/etc/apache2/run/''' existiert. In der Konfigurationsdatei apache2.conf werden folgende Direktiven angepasst:

<pre>
ServerRoot /home/pacs/xyz00/etc/apache2
ServerName xyz00.hostsharing.net

ServerAdmin xyz00@xyz00.hostsharing.net

User xyz00
Group xyz00

Listen 111.222.333.444:8080
Listen 111.222.333.444:8443

NameVirtualHost 111.222.333.444:8443
NameVirtualHost 111.222.333.444:8080

LockFile /home/pacs/xyz00/etc/apache2/run/apache2.lock
PidFile /home/pacs/xyz00/etc/apache2/run/apache2.pid
</pre>

=== Logging ===

ErrorLog /home/pacs/xyz00/var/web.err
CustomLog /home/pacs/xyz00/var/web.log combined

Diese Benennung der Logdateien zusammen mit dem aus der Konfiguration des zentralen Apache übernommenen Format der Logs hat den Vorteil, dass die Logdateien jede Nacht vom zentralen HS-Skript rotiert werden.

=== Einbinden weiterer Konfigurationsdateien ===

Der Apache erlaubt das Einbinden weiterer Konfigurationsdateien mit der "Include"-Direktive. Damit und mittels per Symlink in Verzeichnisse gelinkter Konfigurationsdateien lässt er sich sehr flexibel konfigurieren. Als Beispiel sei die einsehbare Konfiguration des zentralen Apache unter /etc/apache2 genannt. Mit folgenden Beispiel-Direktiven lassen sich alle Dateien von Konfigurationsverzeichnissen einbinden:

Include /home/pacs/xyz00/etc/apache2/conf.d/
Include /home/pacs/xyz00/etc/apache2/mods-enabled/
Include /home/pacs/xyz00/etc/apache2/sites-enabled/

== Start- und Stopskripte ==

Um den eigenen Apache zu starten und zu stoppen, müssen eigene Skripte geschrieben werden. In diesem Beispiel wird angenommen, dass sich die Konfiguration in ~/etc/apache2 (/home/pacs/xyz00/etc/apache2) befindet, dort sind ebenfalls die Skripte für Start und Stop.

=== Startskript ~/etc/apache2/start-apache.sh ===

#! /bin/bash
/usr/sbin/apache2 -f /home/pacs/xyz00/etc/apache2/apache2.conf

=== Stopskript ~/etc/apache2/start-apache.sh ===

#! /bin/bash
pid=$(cat /home/pacs/xyz00/etc/apache2/run/apache2.pid)
kill -TERM $pid

Wenn der eigene Apache mit mod_fcgid läuft, ist es sinnvoll (wenn auch nicht besonders schön oder elegant), bei einem Stop des Apache die unter der eigenen Benutzerkennung laufenden FCGI-Prozesse abzuwürgen. Hier wird angenommen, dass sich die Sockets innerhalb der Verzeichnisstruktur '''~/etc/apache2/run/''' befinden. Das zusätzliche Abwürgen des Apache (trotz vorherigem Beenden weiter oben) und die Löschbefehle für die diversen Socketdateien stammt aus der Konfiguration des eigenen Apachen des Autors und funktioniert so auch.

sleep 1
killall -u xyz00 -KILL apache2
killall -u xyz00 -KILL php
rm ~/etc/apache2/run/fcgisock/*
rm ~/etc/apache2/run/apache2.pid
rm ~/etc/apache2/run/cgisock*

== Überwachung und Start bei Systemstart ==

Die Überwachung des Apachen genauso wie der Start beim Hochfahren des Systems wird mit [[monit_installieren | Monit]] gewährleistet. Dies muss natürlich entsprechend konfiguriert werden.

== Hinweise und Erfahrungswerte ==

== mod_fcgid ==

Die Konfiguration des zentralen Apachen (in /etc/apache2/mods-enabled/fcgid.conf) kann nicht ohne Änderung übernommen werden. Dass der darin befindliche Pfad zum Verzeichnis für die Sockets '''SocketPath /var/run/apache2/fcgisock''' geändert werden muss, sollte klar sein. Aber der Apache möchte mit mod_fcgid noch eine Datei "shm" für Shared Memory anlegen. Und wenn dies nicht explizit konfiguriert wurde, standardmäßig in
/var/lib/apache2/fcgid/shm. Das ist für den eigenen Apache natürlich nicht möglich, er hat da keine Schreibrechte. Er läuft dann zwar ohne Fehler los, liefert aber keine Seiten aus.

Eine funktionierende Konfiguration für mod_fcgid sieht daher so aus:

<pre>
SocketPath /home/pacs/xyz00/etc/apache2/run/fcgisock
SharememPath /home/pacs/xyz00/etc/apache2/run/shm

IPCConnectTimeout 20
IPCCommTimeout 600
IdleTimeout 300
IdleScanInterval 120
BusyTimeout 300
BusyScanInterval 120
ErrorScanInterval 10
ZombieScanInterval 9
ProcessLifeTime 3600
SpawnScoreUpLimit 100
SpawnScore 1.
TerminationScore 2.
MaxProcessCount 250
DefaultMaxClassProcessCount 10
DefaultMinClassProcessCount 3
PHP_Fix_Pathinfo_Enable 1
OutputBufferSize 256

<IfModule mod_fcgid.c>
AddHandler fcgid-script .fcgi
IPCConnectTimeout 20
</IfModule>
</pre>

== Weblinks ==

[http://httpd.apache.org/docs/2.2/ Dokumentation des Apache2.2]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Eigene Daemons]]

RubyOnRails

2012-08-31T10:22:59Z

Srv00-wiki:

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine fertige CMS Anwendung installiert (http://zenadmin.org) und mit einer einfachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

Domainverwaltung

2012-08-31T09:57:55Z

Srv00-wiki: /* Domains neu zuordnen (Domain-Admin ändern, Paketzuordnung ändern) */

{{HSDoku-DomainLinks}}

= Lokale Subdomains =

Subdomains sind Domains unterhalb der Hauptdomain. Also das www in www.example.com, test in test.example.com usw. Bei Hostsharing können beliebig viele verschiedene Subdomains angelegt werden.

== Lokale Subdomains via Verzeichnis ==

Es wird unter [[~/]]doms/example.org/subs/ ein Verzeichnis mit dem Namen "muster" erstellt:

Ergibt http://muster.example.org

== Lokale Subdomains durch Aufschalten / Delegieren ==

Dabei kann die Subdomain muster.example.org im gleichen oder einem anderen Paket aufgeschaltet werden.

* Wenn die Aktion innerhalb eines Pakets durchgeführt werden soll, erfolgt die Einrichtung durch den Paket-Admin mit Hilfe von [[HSAdmin]].

* Wenn die Aktion zwischen Paketen eines Mitglieds durchgeführt werden soll, erfolgt die Einrichtung durch den Mitgliedsaccount (hsh00-xyz) mit Hilfe von [[HSAdmin]].

* Soll eine Subdomain an ein anderes Mitglied delegiert werden, so müssen sich beide Mitglieder mit diesem Wunsch an den Hostsharing-Service wenden. Der Hostsharing-Service schaltet die Subdomain, wenn ihm übereinstimmende Willenserklärungen der beteiligten Mitglieder vorliegen.

= Domains neu zuordnen (Domain-Admin ändern, Paketzuordnung ändern) =

Eine Domain-Verschiebung (neu zuordnen) wird ebenfalls über die DNS Delegation gemacht und erfolgt grundsätzlich über HSAdmin durch Löschen und Neuanlegen der Domain. Da die eigentliche Registrierung über das [http://www.domain-bestellsystem.de Domainbestellsystem] erfolgt, bleibt der Eigentümer der betreffenden Domain durch die Löschung über HSAdmin unverändert.

'''Achtung:''' Das ~/doms/example.org Verzeichnis, also alle Dateien im Webspace werden bei dieser Aktion komplett gelöscht. Sie müssen vorher manuell (am Besten in einem tar-archiv) gesichert werden! Auch die Zuordnung von Mailadressen der betreffenden Domain geht verloren und muß ggf. neu eingetragen werden.

Der Hostsharing-Service (service@hostsharing.net) kann auch Verschiebungen mit minimalen Ausfallzeiten durchführen, bei aufwandsabhängiger Abrechnung gemäß dem Hostmaster-Stundensatz.

= Status der Domaineinrichtung =
Der Domaineinrichtungs-Status kann mit dem hsadmin-[[WebFrontend]] eingesehen werden oder mit [[hsadmin]] auf der Kommandozeile der [[Shell]]:

<pre>
hsadmin -c domain.search
</pre>

= Adresse von Owner / Admin-C ändern =
Die Änderung der Adressdaten erfolgt, indem die Adressdaten des zugehörigen [[Handles]] im [https://www.domain-bestellsystem.de Domain-Bestellsystem] aktualisiert werden.

= Eigene Verwaltung der Zonefiles =
Siehe [[Verwalten der Zonendaten]].

[[Kategorie:HSDoku]]
[[Kategorie:Domains]]
[[Kategorie:Hsadmin]]

RubyOnRails

2012-08-30T15:30:05Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das gleich noch eine fertige CMS Anwendung installiert (http://zenadmin.org) und mit einer einfachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-30T15:28:35Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org) und es mit einer einfachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-30T15:26:37Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-30T14:40:17Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-30T14:21:06Z

Srv00-wiki: /* Bestes Ruby on Rails Hosting bei Hostsharing */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-30T12:46:56Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dieser hält dabei nach einem Aufruf die Ruby Application Server Instanz des Users noch für einige Zeit bereit, die dann sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-30T12:29:54Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dieser hält dabei nach einem Aufruf die Ruby Application Server Instanz des Users noch für einige Zeit bereit, die dann sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß zunächst die Umgebung laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-29T19:28:05Z

Srv00-wiki: /* Bestes Ruby on Rails Hosting bei Hostsharing */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dieser hält dabei nach einem Aufruf die Ruby Application Server Instanz des Users noch für einige Zeit bereit, die dann sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-29T14:26:13Z

Srv00-wiki: /* Konfiguration von FastCGI */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. könnten diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-29T14:20:14Z

Srv00-wiki: /* Konfiguration von FastCGI */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-29T14:18:43Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), und dieses mit einer eifachen sqlite Datenbankdatei einrichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Zena Rails-Anwendung anlegen.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-29T14:12:19Z

Srv00-wiki: /* Bestes Ruby on Rails Hosting bei Hostsharing */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install <Paketname>" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), inklusive automatischer Einrichtung einer sqlite Datenbankdatei:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Legt eine Rails-Anwendung an.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T19:15:56Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install <Paketname>" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen ein Beispiel das auch noch ein fertiges CMS installiert (http://zenadmin.org), inklusive automatischer Einrichtung einer sqlite Datenbankdatei:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Legt eine Rails-Anwendung an.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T19:14:20Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install <Paketname>" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen ein Beispiel das auch noch ein fertiges CMS Framework installiert (http://zenadmin.org), inklusive automatischer Einrichtung einer sqlite Datenbankdatei:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Legt eine Rails-Anwendung an.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T19:14:07Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install <Paketname>" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen ein Beispiel das auch noch ein fertiges CMS Framework installiert (http://zenadmin.org), inklusive automatischer Einrichtung einer sqlite Datenbankdatei:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Legt eine Rails-Anwendung an.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T19:09:45Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
# caused undefined method error:
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install <Paketname>" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen ein Beispiel das auch noch ein fertiges CMS Framework installiert (http://zenadmin.org), inklusive automatischer Einrichtung einer sqlite Datenbankdatei:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Legt eine Rails-Anwendung an.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T19:09:04Z

Srv00-wiki: /* Rails */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
# caused undefined method error:
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install <Paketname>" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen ein Beispiel das auch noch ein fertiges CMS Framework installiert (http://zenadmin.org), inklusive automatischer Einrichtung einer sqlite Datenbankdatei:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Legt eine Rails-Anwendung an.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T19:08:34Z

Srv00-wiki:

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
# caused undefined method error:
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails per "gem install <Paketname>" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen ein Beispiel das noch ein fertiges CMS Framework installiert (http://zenadmin.org), inklusive automatischer Einrichtung einer sqlite Datenbankdatei:
gem install rails -v=2.3.11
gem install i18n sexp_processor sqlite3 zena
zena new ~/rails # Legt eine Rails-Anwendung an.
cd ~/zena-test
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite LANG=en RAILS_ENV=production PASSWORD=geheim HOST=rails.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T17:41:41Z

Srv00-wiki: /* Konfiguration von FastCGI */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
# caused undefined method error:
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails durch installieren des gem-Pakets installiert werden (inklusive Abhängigkeiten).
gem install rails
Um spezielle versionen zu installieren kann man gem Befehle mit "-v=x.y.z" ergänzen.

=== Rails-Anwendung ===

Seine Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails-app/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank je nach Rails-Anwendung.

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T17:20:32Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
# caused undefined method error:
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails durch installieren des gem-Pakets installiert werden (inklusive Abhängigkeiten).
gem install rails
Um spezielle versionen zu installieren kann man gem Befehle mit "-v=x.y.z" ergänzen.

=== Rails-Anwendung ===

Seine Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails-app/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank je nach Rails-Anwendung.

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/ruby/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T17:20:21Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
# caused udefined method error:
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails durch installieren des gem-Pakets installiert werden (inklusive Abhängigkeiten).
gem install rails
Um spezielle versionen zu installieren kann man gem Befehle mit "-v=x.y.z" ergänzen.

=== Rails-Anwendung ===

Seine Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails-app/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank je nach Rails-Anwendung.

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/ruby/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T16:59:00Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails durch installieren des gem-Pakets installiert werden (inklusive Abhängigkeiten).
gem install rails
Um spezielle versionen zu installieren kann man gem Befehle mit "-v=x.y.z" ergänzen.

=== Rails-Anwendung ===

Seine Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails-app/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank je nach Rails-Anwendung.

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/ruby/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T16:42:19Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails durch installieren des gem-Pakets installiert werden (inklusive Abhängigkeiten).
gem install rails
Um spezielle versionen zu installieren kann man gem Befehle mit "-v=x.y.z" ergänzen.

=== Rails-Anwendung ===

Seine Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails-app/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank je nach Rails-Anwendung.

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/ruby/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T16:41:19Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
export RUBYLIB="$HOME/.gem/ruby/1.8/lib/:/usr/local/lib/site_ruby/1.8/:/usr/lib/ruby/1.8/"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails durch installieren des gem-Pakets installiert werden (inklusive Abhängigkeiten).
gem install rails
Um spezielle versionen zu installieren kann man gem Befehle mit "-v=x.y.z" ergänzen.

=== Rails-Anwendung ===

Seine Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails-app/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank je nach Rails-Anwendung.

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/ruby/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T16:29:39Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/bin:$PATH"
export GEM_PATH="$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"
export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8/:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails durch installieren des gem-Pakets installiert werden (inklusive Abhängigkeiten).
gem install rails
Um spezielle versionen zu installieren kann man gem Befehle mit "-v=x.y.z" ergänzen.

=== Rails-Anwendung ===

Seine Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails-app/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank je nach Rails-Anwendung.

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/ruby/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2012-08-28T16:23:32Z

Srv00-wiki: /* Vorinstalliert */

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird ständig eine Ruby Application Server Instanz des Users bereitgehalten, die somit jederzeit zur Bearbeitung von noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung steht.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Wir können auch mod_passenger (mod_wsgi haben wir schon) oder mongrel oder Green Unicorn (gunicorn) installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons buchen, oder können (für größere Projekte) dafür natürlich auch eine beliebige Anzahl ganzer Server buchen.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version verwendet werden, ergänzt man man die ~/.profile:
# enable user's own ruby stuff below $HOME
export PATH="$HOME/bin:$HOME/.gem/bin:$PATH"
export GEM_HOME="$HOME/.gem"
export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8/:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Nun kann Rails durch installieren des gem-Pakets installiert werden (inklusive Abhängigkeiten).
gem install rails
Um spezielle versionen zu installieren kann man gem Befehle mit "-v=x.y.z" ergänzen.

=== Rails-Anwendung ===

Seine Rails-Anwendung kopiert man z.B. nach ~/rails, oder erstellt dort eine Neue (rails ~/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/rails-app/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: example.org
attachments_storage_path: /home/pacs/xyz00/users/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank je nach Rails-Anwendung.

cd ~/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/rails.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf rack middleware aufbauen, laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/pacs/xyz00/users/meinuser/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf der "rack" Middleware aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/rails.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/ruby/.gem/ruby/1.8:/var/lib/gems/1.8'
Evtl. können diese Einstellungen auch ohne eine Modifikation der Anwendung erfolgen, indem die Umgebungsvariablen in der .htaccess gesetzt werden (z.B. "SetEnv RAILS_ENV production").

Die Applikation ins Webroot einbinden:

# ggf. vorhandene Dateien sichern (oder nach ~/rails/public kopieren)
mv ~/doms/rails.example.org/htdocs ~/doms/rails.example.org/htdocs.old
# Das rails/public Verzeichnis ins Webroot verlinken.
ln -s ~/rails/public ~/doms/rails.example.org/htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/rails.example.org/fastcgi-ssl/ und ~/doms/rail.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]