== foswiki ==

=== installazione di una istanza ===

Il software non viene installato system wide, in modo da permettere
di avere, sulla stessa macchina, diverse installazioni, anche con
versioni differenti.

Se non si impostano manualmente i parametri viene utilizzata l'ultima
versione descritta da kusa.

  * connettersi con il progetto di gestione web, ad esempio:
  {{{
cj www
  }}}

  * posizionarsi nella directory dei documenti html per il virtual host
  apache scelto per l'istallazione, eventualmente anche quello di default
  della macchina, ad esempio:
  {{{
cd $PRJ/vhosts/default/docs
  }}}
  
  * creare eventualmente (scelta consigliata) una subdirectory per
  l'installazione della wiki e posizionarsi in quest'ultima da qui lanciare
  l'installer:
  {{{
mkdir wiki
cd wiki
foswiki-install
  }}}

  * se non e` presente un file ".install" questo verra` creato, modificarlo
  cambiando i parametri che non corrispondono alle proprie esigenze, i
  parametri che non cambiate cancellateli, di norma l'unica riga necessaria
  e` quella relativa al nome fqdn del server (di default viene usato l'uname,
  che essendo il nome della rete interna non corrisponde quasi mai al virtual
  host che si sta utilizzando), ad esempio:
  {{{
foswiki_defaulturlhost='http://devel.kubit.ch'
  }}}

  * dal browser entrare sulla pagina di configurazione della wiki, es:
  {{{
http://server.miodominio.com/wiki/bin/configuration
  }}}
  per entrare occorre autenticarsi tramite l'autenticazione base di apache,
  le credenziali sono:
  {{{
username: admin
password: admin
  }}}

  * impostare i parametri non inizializzati di default dall'installer, in
  particolare occorre inserire l'email dell'amministratore della wiki (di
  norma il webmaster), ed eventualmente inserire gli URL alternativi con i
  quali si puo` arrivare alla wiki

  * impostare anche la password di amministrazione del sito, che NON e`
  quella dell'autenticazione base di apache descritta sopra, ma quella
  usata internamente da foswiki per l'utente AdminUser; a questo scopo
  prima di salvare le modifiche alla configurazione occorre spuntare
  l'opzione "Change password"

  * controllare gli eventuali altri errori e warnings; notare che le
  impostazioni sui permessi delle directory del quale si lamenta vanno
  in realta` benissimo (l'installer le imposta con l'acceso in scrittura
  anche per il gruppo, in modo da poterle gestire in un ambiente multiutente)

  * creare un utente amministratore (reale) come suggerito dalla pagina
  finale del configuratore, esempio: "kusa", editare il gruppo AdminGroup
  ed aggiungere l'utente amministratore

=== post install ===

==== apparenza ====

  * modifiche da effettuare nelle preferenze del web Main:
  [/wiki/bin/view/Main/WebPreferences], utilizzando preferibilmente
  il raw edit (Edit wiki text)

  * cambiare il logo: aggiungere (es):
  {{{
   * WEBLOGOIMG = /images/company-logo-mini.png
  }}}

=== NOTE SU PAM (dannata security) ===

The Linux PAM implementation as one would expect supports many 
different authentication mechanisms.  If a service is PAM-aware,
you can plug in a number of default modules or write a custom one
if you like.

No surprise there, this is what PAM is supposed to do across all 
flavors that support it.  The core module configured if you need
to authenticate against the standard /etc/password and related
database files is pam_unix.
It also supports authentication when using a shadow file 
(/etc/shadow).
The shadow file is used for enhanced security against brute force 
password crack attacks where you store the actual password hashes
in the shadow file which can only be read by root.
The default security configuration on recent 
redhat-like flavors from my experience uses a shadow file.  This 
poses a problem if you need a non-root user to be able to 
authenticate against the shadow file.  Here is the pam_unix approach:

  * 1. install a setuid root executable /sbin/unix_chkpwd helper binary 
  that can read /etc/shadow on behalf of the user
  * 2. when using PAM-enabled services to authenticate from a process 
  with real uid > 0, pam_unix calls out to the setuid root unix_chkpwd
  * 3. the unix_chkpwd checks to see if the real uid of the process 
  matches the username argument seeking authentication
  * 4. if the real uid matches the authenticating username, it retains 
  euid=0 status so that the user can continue the authentication 
  process against /etc/shadow
  * 5. if the real uid does not match the authenticating username, it 
  sets the euid to be the real uid of the user process calling 
  unix_chkpwd

Step 5 is where the problem occurs.  Not retaining euid=0 prevents 
unix_chkpwd from reading /etc/shadow and authentication will fail 
logging 'check pass; user unknown' to syslog. This message is 
confusing since it seems to imply that the process does not know the 
authenticating username, but clearly it does because additional 
syslog messages that follow indicates that auth failed for username.  
This is just an artifact of the hard coded error message in 
unix_chkpwd.

The bottom line for your software users using UNIX authentication via 
PAM on Linux with shadow password database is this.  If you run your 
software as root, pam_unix will never even bother calling unix_chkpwd 
because it does not need to.  Voila...your users get authenticated.  
If you run your software with uid > 0, then the only user you can 
authenticate successfully is the username whose uid matches the 
process running your software.  Clearly this is not acceptable for 
most usages since only one user can log in.  To fix this, you can do 
one the following things in order of increasing security.

  * 1.  Run your software as root.  This is unacceptable in many 
  enterprise environments that have internal IT SOPs against this.  It 
  can be a major security issue based on the configuration of the 
  underlying Java policy.
  * 2.  Create a special group (say shadow) that can read /etc/shadow and 
  assign the user running your software to that group.  This is better, 
  but does allow enhanced access to the password hash file to anyone 
  running code in your software, or who gains access to any kind of 
  your software user process (such as a shell).
  * 3.  Hack /sbin/unix_chkpwd (or provide a different helper binary) so 
  that it does not change euid from 0 to real uid when it detects that 
  the real uid does not match the authenticating username.

This last option represents a reduced yet real security risk by 
potentially allowing the setuid binary to be used in brute force 
password crack attacks such as those that can be performed when not 
using a shadow file.  However, the source code to the binary does 
reveal that the designers added some additional features to ward this 
off such as not allowing the password you are testing to come from 
standard input generated by a TTY.  The switch euid to real uid when 
the authenticating username does not match real uid is an additional 
measure.  It restricts the attacker from using brute force attack to 
obtain the password for a user they do not already have access to.  
Anyone who considers hacking the binary to remove the euid swich 
should probably disallow an authenticating username that is root or 
any other system-privileged user.

Also now that I think about it, it is a fair debate that the order of 
options 2 and 3 should be reversed.  It can be argued that the euid 
switch to real uid by unix_chkpwd is a good idea for enhanced 
security especially since euid 0 ultimately has full control of 
/etc/shadow, which includes chmod and write.  A gifted hacker could 
exploit unforseen security holes in unix_chkpwd in an open source 
world.  Instead, granting ro access to a shadow group gives you a 
little more control.

