What’s the best way of handling permissions for apache2’s user www-data in /var/www ?

Tagged:

Avec des Acls

I think you may find POSIX ACL (access control lists) to be helpful. They allow a finer-grained permission model compared to the user:group:other model. I have found them to be easier to keep straight in my head since I can be more explicit and can also set the "default" behavior for a branch of the file system.

For example, you can specify each user's permissions explicitly:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Or you can do it based on some shared group:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

And perhaps you want to keep your Apache user as read-only

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Man pages:

Apt-Pinning for Beginners

Why apt-pinning?

Do you run Debian? Have you ever gotten annoyed at how Debian Stable always seems to be out of date?

I will show you a way that you can have apt mix-and-match between Stable, Testing, and Unstable sources. This will allow you to run a mostly-Stable system, but also track the latest and greatest of those packages that you are most keenly interested in.

Why do this? Stable is covered by the Security Team. Testing and Unstable are not. For non-critical services, like perhaps your mailer, or your window manager, this is not so important, and the newest versions may have additional features that are desired. It is these packages that are perfect for pinning to a version, other than Stable.

sources.list

The first step is to set up your /etc/apt/sources.list to include your typical Stable, plus the Testing/Unstable sources that you want.

A simple sources.list may look like this:

#Stable
deb http://ftp.us.debian.org/debian stable main non-free contrib
deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free

#Testing
deb http://ftp.us.debian.org/debian testing main non-free contrib
deb http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free

#Unstable
deb http://ftp.us.debian.org/debian unstable main non-free contrib
deb http://non-us.debian.org/debian-non-US unstable/non-US main contrib non-free

You would probably want to add your mirrors, security.debian.org, and perhaps the appropriate deb-src lines. Here is a copy of my actual sources.list.

preferences

The next step is to create/edit your /etc/apt/preferences file. preferences is where the apt-pinning takes place. Normally, the highest version of an available package wins, but we will override that.

A simple preferences file may look like this:

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=testing
Pin-Priority: 650

Package: *
Pin: release a=unstable
Pin-Priority: 600

Note the decending values. Since Stable has the highest pin-priority, it will be installed preferentially over Testing or Unstable.

My actual preferences file is what you see above.

apt-get update

Now we are ready to apt-get update. This will add the new repositories to apt's list.

E: Dynamic MMap ran out of room

You may find that you receive an error like the following:

E: Dynamic MMap ran out of room
E: Error occured while processing sqlrelay-sqlite (NewPackage)
E: Problem with MergeList /var/lib/apt/lists/ftp.us.debian.org_debian_dists_woody_contrib_binary-i386_Packages
E: The package lists or status file could not be parsed or opened.

This is caused because apt's cache is too small to handle all of the packages that are included with stable, testing, and unstable. This is also very easy to fix. Add the following line to /etc/apt/apt.conf

APT::Cache-Limit "8388608";

Thanks to R (Chandra) Chandras for pointing out this problem

Installing new packages

To install a new package, it is just as it ever was, apt-get install <package>. If the package exists in Stable, then that is what it will grab. If the package exists only in Unstable, then from Unstable it will be gotten.

What if the package exists in both Stable and Unstable, but we want the Unstable version? There are two ways we can do that, each with a slightly different syntax, and each with a slightly different effect.

apt-get install <package>/unstable

This will install the unstable version of the package, and try to meet any dependencies from Stable. This may not work, but it will tell you why:

# apt-get install zsh/unstable
Reading Package Lists... Done
Building Dependency Tree... Done
Selected version 4.0.6-7 (Debian:unstable) for zsh
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

Sorry, but the following packages have unmet dependencies:
  zsh: Depends: libc6 (>= 2.2.5-13) but 2.2.5-11.1 is to be installed
E: Sorry, broken packages

apt-get -t unstable install <package>

This will install the Unstable version of the package, and try to meet any dependencies from Unstable. This may produce better results.

# apt-get -t unstable install zsh    
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  libc6 libc6-dev libc6-pic libdb1-compat locales 
The following NEW packages will be installed:
  libdb1-compat 
5 packages upgraded, 1 newly installed, 0 to remove and 394  not upgraded.
Need to get 11.6MB of archives. After unpacking 606kB will be used.
Do you want to continue? [Y/n]

That's it!

Armed with a complete sources.list and a minimal preferences, you can go ahead and mix-and-match between the various Debian releases.

Have fun!

SVN fusion des révisions de trunk dans votre branche

Tagged:

À partir de la branche

svn log

Affiche le numéro de révision lors de la création de ma branche

------------------------------------------------------------------------
r23 | stereosv | 2009-02-17 11:42:28 -0500 (Tue, 17 Feb 2009) | 1 line

creating branch for xyz

Maintenant j'ai besoin de connaître la révision actuelle du trunk. La commande svn update exécutée à partir du trunk retourne la version actuelle.

> svn update
At revision 25.

Dans mon cas, le trunk est à la révision 25... impliquant qu'il n'y a eu que deux commit depuis la dernière fois que j'ai checked out ma branche. Sympa.

Maintenant, il faut transporter ces changements dans ma branche. De retour sur le répertoire de ma branche, il est temps de mettre les numéros de révision.

svn merge -r 23:25 svn+ssh://username@svnserver/home/username/svn/project/trunk

Ce qui est fait est un merge de tous les changements survenus entre la révision 23 (quand j'ai créé ma branche) et la révision 25 (la version la plus récente du trunk) dans le trunk dans ma copie locale.

Maintenant il est temps de check in ma branche, avec les changements mise à jour à partir du trunk.

svn ci -m "Merged trunk changes r23:25 into my branch"

Se connecter en SSH avec sa clé publique

Se connecter en SSH avec sa clé publique (plutôt que son mot de passe) présente quelques avantages : sécurité renforcée, possibilité de définir un mot de passe « vide »... Voici les étapes à suivre pour configurer son compte SSH avec clé publique :

Générer sa clé privée sous Windows

Nous allons utiliser le générateur de clés fournis avec PUTTY, un logiciel gratuit, disponible à cette adresse: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html (choisir le "Windows Installer", ou bien télécharger puttygen.exe).

Lancer PuTTYGen, générer une paire de clé SSH-2 DSA de 1024 bits et sauvegarder la clé privée dans un dossier personnel de votre ordinateur. Copier la clé publique affichée (avec un CTRL-C) et la sauver dans un fichier temporaire authorized_keys (il ne faut pas cliquer sur Save Public key mais bien faire un copier-coller).

Exemple de clé publique (sur une seule ligne):

ssh-dss AAAAB3NzaC1kc3MAAACBALWEC3j9qDVBUD2GDSiGA7N265of/V0vFXql21tbLLoLxboVy6usY4mcwRtWHes9MvDv64TWH81I72pwUtRqsfnsWuuvq3X/Pw6FWdMKWo91+B+xNDlZE6HmW6PigM4pqXDsiwvP3/CA1rgF/Dkaeq3UVyVux5ZbKexb/JsBC4I9AAAAFQDpGJFV1yrx6AcwuT61jSZ3JIPrxQAAAIBXDoi7WeNfoGMpcw0LaeMzROVr53q3+rUS99kyi6153TSiDph8RlURuBU2C4y67lARYqJy/9Hbm7mShKEUkXhrDacevJfuF5zI9WJ5Jkqt/FtPDzhEmWqhW6EDlckeQFgRM4NE32uBOCEIGb0Ac7M5QY/t+igb49nrq79goYMxdQAAAIARjdjIlrzwa5iew8CKuf97DTCbGy9I4ZLpE9GVCLEi/mgm4+JOCD8Y3exlNdWJogmcc/ec1wJzdP7zgm/I7uraoL6B7BeGfzdQ2KWWvNL7unhGW2q8Rwegh9aQJnapCQ/0irTHhx65XB3oq+Yk30GDEtYioewuGAvSXH8TD0Dtgw== dsa-key-20090731

Uploader sa clé sur le serveur depuis Windows

A l'aide de votre logiciel FTP, créer le dossier .ssh (activer l'option "Afficher les fichiers cachés" pour visualiser le dossier créé). Mettre le fichier authorized_keys dans ce dossier .ssh.

Se connecter en SSH Depuis Windows

Lancer PUTTY.exe. Lors de la première connexion, il faut configurer une session:

Dans la colonne de gauche "Category", choisir SSH et renseigner:

  • Prefered SSH Protocol version: 2
  • Développer (cliquer sur +) pour afficher l'option Auth, et dans Private Key file for auth, indiquer le chemin pour accéder à votre clé privée sur votre ordinateur.

Retourner à la catégory Session, et cliquer sur "save".

Désormais, vous avez configuré une session, que nous avons appelé ssh.alwaysdata.com, qui pourra être utilisée directement ou via SVN.

Double-cliquez sur cette session. Vous devriez être connecté automatiquement, grâce à votre clé privée.

Générer sa clé privée sous Linux ==

$ mkdir -p ~/.ssh
$ chmod 0700 ~/.ssh
$ ssh-keygen -t dsa -f ~/.ssh/id_dsa

Si vous voulez ne jamais avoir à rentrer votre mot de passe lorsque vous vous connecterez en SSH, indiquez une « passphrase » vide.

Uploader sa clé sur le serveur depuis Linux

ssh-copy-id -i ~/.ssh/id_dsa.pub user@ssh.alwaysdata.com

Remplacez « user » par le nom de votre utilisateur SSH.

Uploader sa clé sur le serveur depuis Mac OS X (ou si ssh-copy-id n'est pas disponible)

Copiez votre clé sur votre compte

scp ~/.ssh/id_dsa.pub user@ssh.alwaysdata.com:/home/user

Connectez-vous en ssh avec votre nom d'utilisateur et mot de passe et copiez le contenu de la clé dans .ssh/authorized_keys

mkdir -p ~/.ssh
chmod 0700 ~/.ssh
cat id_dsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Supprimez enfin le fichier id_dsa.pub

rm id_dsa.pub

Se connecter en SSH Depuis Linux

À la prochaine connexion SSH, votre passphrase vous sera demandée (ou rien du tout si votre passphrase est vide).

Si cela ne fonctionne pas ...

  • Vérifiez que le fichier authorized_keys se trouve bien dans le dossier .ssh dans le dossier de démarrage de l'utilisateur SSH. Pour l'utilisateur <user>, c'est /home/<user>/. Si vous avez créé un autre utilisateur SSH, c'est le dossier que vous avez désigné lors de sa création.
  • Dans le fichier authorized_keys, vérifiez que la clé publique est bien sur une seule ligne, et ne contient pas de commentaires ou autres caractères etranges.

Installation de ROR

Ruby

Sur debian

> sudo apt-get install ruby1.8-dev

Ruby of Rails

en étant l'utilisateur root

> gem install rails

driver mysql

Normalement

> gem install mysql

sinon sous OSX

> sudo gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

mod_rails

en étant l'utilisateur root

> gem install passenger
> passenger-install-apache2-module

Coller les lignes dans le httpd.conf d'apache. Sous OSX, ces lignes sont

LoadModule passenger_module /Library/Ruby/Gems/1.8/gems/passenger-2.2.4/ext/apache2/mod_passenger.so
PassengerRoot /Library/Ruby/Gems/1.8/gems/passenger-2.2.4
PassengerRuby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Ajouter un vHost par domain

<VirtualHost *:80>
    ServerName www.foo.com
    DocumentRoot /webapps/foo/public
    RailsBaseURI /rails
    RailsEnv development

    <Directory "/webapps/foo/public">
        Options FollowSymlinks
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>

</VirtualHost>