Establecer update alternatives a machete

Cando por exemplo ó configurar a alternativa para o navegador sae o seguinte erro:

$ update-alternatives --set x-www-browser /usr/firefox
update-alternatives: error: alternative /usr/firefox for x-www-browser not registered, not setting.

Isto pode ser debido a que o firefox está instalado a man en /opt. Unha solución para establecelo a man é facelo directamente en /etc/alternatives/, algo así:

$ sudo rm /etc/alternatives/x-www-browser
$ sudo ln -s /usr/firefox /etc/alternatives/x-www-browser

Fonte: shallowsky

Alternativas a Crunchbang#!

Unha vez que morreu o proxecto Crunchbang busquei alternativas. De momento as máis intersantes das que atopei foron estas:

BunsenLabs que é á que se pode acceder desde a web de crunchbang.

Nesta páxina da wikipedia que curiosamente non fala nada de BlusenLabs nomean a CrunchBang++

E hai máis, en desdelinux.net atopei a proposta de Semplice, que é unha distribución tamén baseada en Debian, algo que me gustou é que teñen versións para 32 e 64 bits e o máis interesante é que teñen versión baseada en debian estable e outra en inestable (sid).

Neste artigo de entornosgnulinux falan de TweakLinux como outro sucesor de CrunchBang.

Agora toca ir probando a ver con cal me atopo máis a gusto.

Configurar sftpd con usuarios engailoados

Os servizo ssh permite a conexión cun servidor remoto e xunto con isto permite conectar co mesmo a traveso do protocolo sftp, algo similar ó FTP que funciona de xeito máis seguro. Moitos clientes FTP (como Filezilla) incorporan a posibilidade de conectar mediante o sftp.

Ó instalar o servidor ssh no servidor, este xa queda dispoñible para ser empregado cos nosos usuario a traveso dun cliente sftp. Isto ten un problema, e é que o cliente sftp pode navegar por todo o sistema de ficheiros expoñendo o contido de todo o servidor. Como isto non é nada bo comento como facer para que isto non pase.

Unha solución a isto é engaiolar (chroot) os usuarios para que non poidan navegar polo sistema de directorios do servidor. Isto permite que estes usuarios poida subir ficheiros nun cartafol espedificado para o seu usuario.

Como lograr isto?

Primeiro asegureime que existe en /etc/shells o ficheiro nologin.

# less /etc/shells

Como non existía o shell nologin na lista, engadín ó final a seguinte liña:

# echo "/usr/sbin/nologin" >> /etc/shells # Usuarios Debian/ubuntu 10.4
# echo "/sbin/nologin" >> /etc/shells  # Usuarios Ubuntu 12.4

Logo creei un grupo novo. Os usuarios deste grupo terán de xeito automático restrinxido o acceso ó sistema de directorios tendo acceso só ó seu directorio engaiolado. Non poden saír e perderse mais aló do seu directorio raíz.

# groupadd hostusers

Creei o usuario que vai estar engaiolado. Este usuario ten a particularidade de que non poderá acceder a un terminal e só poderá acceder mediante un cliente sftp ós seus directorios engaiolados.

# useradd -g hostusers -d /home -s /usr/sbin/nologin testuser  # usuarios Debian/ubuntu 10.4
# useradd -g hostusers -d /home -s /sbin/nologin testuser  #usuarios Ubuntu 12.4
# passwd testuser  #para establicer a clave

Verifiquei que o usuario foi creado.

# grep testuser /etc/passwd

Configurei o servizo engaiolado. Para elo modifiquei o ficheiro sshd_config que é onde se configura o servizo do servidor ssh (neste ficheiro ssh é onde se establece como queremos que funcione), neste caso mudei o servidor que ven predeterminado por internal-sftpd.

# nano /etc/ssh/sshd_config

Comentei a liña:

#Subsystem sftp /usr/lib/openssh/sftp-server

Ó final do ficheiro engadín a seguinte liña nova (para que empregue o sftp interno) É importante que isto se engada ó final para evitar o erro «Directive 'UsePAM' is not allowed within a Match block.».

Subsystem sftp internal-sftp

E de seguido engadín o seguinte texto que fará que os usuarios do grupo hostusers estean engaiolados cando acceden mediante sftpd. É importante que isto vaia despois da liña «Subsystem sftp internal-sftp» .

Match Group hostusers  # Só se aplica ós suarios do grupo hostusers
ChrootDirectory /hosting/%u  # Os usuarios están engaiolados nun cartafo co seu nome de usuario
ForceCommand internal-sftp  # Forzase ós usuario a usar o sftp interno

Logo creei o directorio da gaiola.

# mkdir /hosting

Creei os directorios para o usuario testuser.

# mkdir /hosting/testuser
# mkdir /hosting/testuser/home
# mkdir /hosting/testuser/home/public_html

O cartafol /hosting/testuser será como / para o usuario testuser. Este usuario non poderá ver nada por riba do seu directorio raíz. O directorio public_html queda aí para poder usalo con Apache e orientar os dominios virtuais a ese directorio. De xeito que cando esta configurado Apache, o que cada usuario poña aí publicarase en internet.

Cambiei os propietarios. Como os directorios que creei foron co usuario root, cambielles o propietario para que o usuario testuser poida usalos.

# chown testuser:hostusers /hosting/testuser/home
# chown testuser:hostusers /hosting/testuser/home/public_html

Asegúrome de que os permisos do cartafol do usuario son 755. Isto é moi importante xa que se o grupo ten permiso de escritura non vai.

# chmod 755 /hosting/testuser

Comprobei os propietarios.

ls -ld /hosting/testuser/home

Reiniciei o servizo ssh para que os cambios que fixen teñan efecto.

# service ssh restart

Logo accedín con un cliente sftpd (por exemplo o Filezilla).

No caso de que queira engadir máis usuarios engaiolados tería que repetir para cada novo usuario as seguintes accións:

  • Creación do usuario
  • Creación dos directorios
  • Aplicación dos permisos dos cartafoles para ese usuario
  • Reiniciar o servizo ssh.

Con estas instrucións permito que os usuarios suban ficheiros ó servidor e non poidan comprometer a visibilidade dos contidos nel. No meu caso foi para un ubuntu 10.4.

Deixo aquí este código «crea_usuario.sh» que automatiza o proceso de creación de novos usuarios engaiolados.

#!/bin/bash

echo "Usuario:" $1
echo "Clave:" $2

useradd -g hostusers -d /home -s /usr/sbin/nologin $1
#passwd -f $1 $2
echo -e "$2\n$2" | passwd $1

mkdir /hosting/$1
mkdir /hosting/$1/home

chown $1:hostusers /hosting/$1/home

chmod 755 /hosting/$1
chmod 755 /hosting/$1/home

service ssh restart

Supoñendo que o usuario a crear fose usuario2 e a clave r2k7GWcs lanzariase así:

# ./crea_usuario.sh usuario2 r2k7GWcs

Fontes: nireleku - ciberciti.

Agachemanto e pesa de man

Estes son os termos que propón un idioma preciso para o que en español se coñece como sentadilla e mancuerna.

Erro ao instalar cx_Freeze 4..3.4 no debian Jessie

Ao tratar de instalar o cx_freeze 4.3.4. no Debian Jessie mediante a orde:

$ sudo pip install cx_Freeze

atopeime co erro:

/home/thomas/Code/cx_freeze/source/bases/Console.c:36: undefined reference to `PyErr_Print'

A solución atopeina na páxina de erros do cx_freeze en concreto é a que suxire Tim Süberkrüb.

For python 2.7:

sudo apt-get install python-dev

sudo apt-get install libssl-dev

Open setup.py and change the line

if not vars.get("Py_ENABLE_SHARED", 0):

to

If True:

python setup.py build
sudo python setup.py install

Crear paquete executable con cx_freeze

Até o de agora viña usando py2exe para a xeración de executables. Tiña gañas de probar unha alternativa que fose multiplataforma como é o caso de cxFreeze.

Neste caso o sistema operativo é un windows, onde instalei a versión cx_Freeze-4.3.3.win32-py2.7 pero resulta.

Probeino co proxecto auto_licenzas, e daba o erro:

File "C:\Python\virtualenvproject\lib\site-packages\cx_freeze-4.3.4-py2.7-win32.egg\c x_Freeze\freezer.py", line 270, in _GetDefaultBinPathExcludes import cx_Freeze.util ImportError: DLL load failed: The specified module could not be found.

(ImportError: DLL load failed: No se puede encontrar el m¾dulo especificado.)

Despois de buscar un cacho atopei a solución aquí.

Basicamente ben a dicir que é un erro da versión 4.3.4 e que instalando a versión 4.3.3 se soluciona.

E así foi!! Así de simple!!

Amosar o tamaño das imaxes na barra de estado do Thunar

Cando actualicei de debian wheezy a jessie desapareceume esta opción, buscando achei o xeito de recuperala.

Para elo executei na consola a seguinte orde:

xfconf-query --channel thunar --property /misc-image-size-in-statusbar --create --type bool --set true
Tal como indican na web de xfce - thunar.

Openbox PolicyKit authorization failed ó conectar modem USB

Resulta que despois de actualizar o crunchbang de debian wheezy a jessie ó conectar o modem USB atopeime este erro no momento de meter o PIN:

PolicyKit authorization failed: challenge needed for 'org.freedesktop.ModemManager1.Device.Control'

Procurando probei esta solución:

1. open Default Apps for LXSession
 2. click on "autostart tab"
 3. make sure "PolicyKit Authentication Agent" is checked

Pero no meu caso non funcionou, eu penso que é porque teño openbox.

Finalmente atopei isto nos foros de crunchbang:

Executei isto no terminal:

/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &

E xa foi.

Para facer que isto sexa permanente, puxen dita liña no autostart.

Instalación do awstats no debian baixo apache

Aquí deixo estas notas sobre como me foi a instalación do awstats, nun debian wheezy máis nun ubuntu 10.04 tls, en ambos serviu a mesma configuración.

Instalación

# sudo apt-get install awstats

Configuración

Unha vez instalado, temos os ficheiros de configuración en /etc/awstats/, o modelo chámase awstats.conf. Se o sitio a estatisticar é www.damufo.com creamos o ficheiro de configuración para o mesmo do seguinte xeito (se tivesemos máis dun dominio, creariamos un ficheiro por dominio):

# cp /etc/awstats/awstats.conf /etc/awstats/awstats.www.damufo.com.conf

Unha vez creado o ficheiro de configuración para o dominio a estatisticar ábrese cun editor de texto simple como por exemplo o nano:

# nano /etc/awstats/awstats.www.damufo.com.conf

e realízamos os seguintes cambios:

LogFile="/var/log/apache2/access.log" 
SiteDomain="www.damufo.com"
HostAliases="localhost 127.0.0.1 www.damufo.com"  #aquí podemos engadir tamén o enderezo ip local da máquina
Logo xeramos as estatísticas as cales se basean no ficheiro /var/log/apache2/access.log:
#  /usr/lib/cgi-bin/awstats.pl -config=www.damufo.com -update

Configuración Apache2

O primeiro é activar o mod_cgi para elo, empregamos a orde

:
# a2enmod cgi

Logo imos ó sitio ó ficheiro de configuración do apache para o sitio, os sitios activados están en /etc/apache2/sites-available/

# cd /etc/apache2/sites-available/
#nano  /etc/apache2/sites-enabled/000-default

E dentro das etiquetas virtualhost engadimos:

Alias /awstatsclasses "/usr/share/awstats/lib/"
Alias /awstats-icon "/usr/share/awstats/icon/"
Alias /awstatscss "/usr/share/doc/awstats/examples/css"
ScriptAlias /awstats/ /usr/lib/cgi-bin/

Estas son as opcions de seguranza, as cales só permiten o acceso ás estatísticas ós equipos que están dentro da rede local.

<Directory /usr/lib/cgi-bin/>
    Deny from All
    Allow from 192.168.0.0/24  # IP address you allow
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
</Directory>

Outra posibilidade se seguranza é poñerlle clave de acceso ó cartafol, para elo fixen isto:

# htpasswd -c /etc/apache2/.htpasswd user1
# htpasswd /etc/apache2/.htpasswd user2

Debaixo de ScriptAlias.. Quedaría isto:

  <Directory /usr/lib/cgi-bin/>
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    AuthType Basic
    AuthUserFile /etc/apache2/.htpasswd
    AuthName "Enter password"
    Require valid-user
  </Directory>

Reiniciamos apache2:

Uso reload porque modifiquei ficheiros de configuración do apache, hai máis información aquí.
# /etc/init.d/apache2 reload

ou

# service apache2 reload

Unha vez feito isto deberiamos ter dispoñibles as estatísticas en:

http://www.damufo.com/awstats/awstats.pl?config=www.damufo.com

Configuración de crontab

Para que as estatísticas se actualicen automaticamente engadimos a seguinte liña no crontab, se tivesemos máis dun (dominio teriamos que engadir unha para dada dominio):

# nano /etc/crontab
25 2    * * *   root    /usr/lib/cgi-bin/awstats.pl -config=fegan.fegan.org -update > /dev/null

Creación ficheiro estático coas estatísticas

Tamén se pode crear un ficheiro estático mediante a orde:

# /usr/lib/cgi-bin/awstats.pl -config=www.damufo.com -output -staticlink > /var/www/awstats/index.html

Isto último non o teño moi probado, deixoo para máis adiante.

Fontes: ubuntu.com, pc-frek.net, debiantutorials.com

Mini guia virtualenv para debian jessie

Instalación

sudo apt-get install python-virtualenv
sudo apt-get install virtualenvwrapper

Uhna vez instalado, é preciso crear un directorio para almacenar os virtualenvs:

mkdir $HOME/.virtualenvs

De seguido hai que engadir as seguintes liñas ó final do documento ~/.bashrc:

export WORKON_HOME=~/.virtualenvs
 # esta liña de abaixo muda respecto de archlinux e en debian queda así
source /etc/bash_completion.d/virtualenvwrapper 

Para activar estas liñas é preciso reiniciar a sesión ou executar:

source ~/.bashrc

Pode acharse información extensa sobre o uso de virtualenvwrapper na páxina de Doug Hellmann.

Uso básico

Ver a lista de virtualenvs instalados:

$ workon

Crear un novo virtualenv:

$ mkvirtualenv -p /usr/bin/python2.7 mi_env

Activar o virtualenv:

$ workon mi_env

Instalar un paquete (p.ej. Django) no virtualenv:

$ (mi_env)$ pip install django

Traballar no proyecto

Saír do virtualenv:

(mi_env)$ deactivate

Fonte: archlinux

Amosando 41 a 50 de 324