Set static IP on your openSUSE Raspberry Pi
In openSUSE is easier. Everything can be done under YaST.
1. Open YaST and go to Network Devices>Network Settings.

2. Then choose Statically Assigned IP Address (move with tab button and click on space button). Give the static IP you want (IP address needs to be in the same range as the router's) and as Subnet Mask, 255.255.255.0. Press Next (press enter).

3. You'll see an overview of the ethernet card.

4. Go to Hostname/DNS and add Google's DNS servers (optional).

5. Next, go to Routing and add your router ip (usually 192.168.1.1).

Now press OK, reboot and try to login again with SSH.
GIF animados
De vez en cuando grabo algún vídeo ó secuencia de fotos del que me gusta extraer fotogramas y crear/componer un GIF animado, muchos los he ido colgando por aquí. Un GIF animado es una pieza gráfica especial, singular, a medio camino entre la fotografía y el vídeo, sin la perfección y nitidez de una ni la toda la información visual/sonora del otro pero con un espacio propio dentro del cual funciona mejor y supera a ambos en simpleza y capacidad visual.
Llevaba tiempo queriendo integrarlos en el blog. Como galería independiente me parecía algo excesivo así es que finalmente he optado por modificar el código que gestiona la galería de Fotografías (alojadas en Flickr) para que integre ahora además los GIFS animados que alojados en Picasaweb. En adelante, la galería de fotos estará un poco más animada.
Un GIF es un formato de archivo de imagen reducido a 256 colores que contiene uno o varios fotogramas. Estos fotogramas son interpretados de forma nativa por cualquier navegador web y reproducidos de forma cíclica (normalmente, no tiene porqué ser así) sin necesidad de aplicaciones extras como pueden necesitar los archivos de vídeo.
Para realizar un GIF animado hay cienes y cienes de herramientas. En GNU/Linux podéis hacer un GIF animado directamente desde un vídeo con FFMPEG o MENCODER, pero para hacer un buen GIF animado, cíclico y optimizado en color y peso lo mejor es crearlos a partir de una pila de imágenes con IMAGEMAGICK.
Crear GIF animado desde consola
En una carpeta temporal vuelca las imágenes que componen los fotogramas. Si sólo tienes el vídeo puedes extraer los fotogramas con MPLAYER haciendo lo siguiente:mplayer -vf screenshot mipelicula.avi
Durante la reproducción pulsa «s» para tomar un fotograma instantaneo o pulsa «MAYUSCULAS+s» para comenzar a generar fotogramas a cada frame hasta que vuelvas a pulsar «MAYUSCULAS+s». (cuidadito! con dejar pulsado «MAYUSCULAS+s» con un vídeo de 1:30 horas porque producirás varios cientos de miles de PNG en un plis-plas).
Una vez tengas los fotogramas que compondrán el GIF animado ayudate de cualquier visor de imágenes ( yo uso VIEWNIOR ) y visualiza los frames extraidos para ir eliminado los primeros y últimos hasta conseguir una secuencia que cicle correctamente, es decir, que el último fotograma y el primero sean tan parecidos que den fluidez a la secuencia. Si por ejemplo con mplayer extrajiste una serie de fotogramas del shot00001.png -> shot0124.png, después de ir eliminado fotogramas te podría quedar una secuencia de 50 imágenes dek shot0010.png -> shot0060.png.
Ahora puedes convertir esta secuencia de 50 pngs en un GIF haciendoconvert -fuzz 5% -delay 1x12 shot*png -resize 720 -layers OptimizeTransparency secuencia.gif
Con delay 1×12 (mostrar cada frame 1/12 de segundo) controlas la velocidad de reproducción del GIF. Fuzz 5% indica cuanto color se puede perder en la comparación (cuanto más alto, menos calidad, menos peso del archivo). Resize reescala la imagen resultante (a más tamaño, más peso). OptimizeTransparency calcula y elimina aquellas partes de que repiten entre fotogramas y por lo tanto se puede optimizar.
Trucos
Si no queréis borrar fotogramas podéis hacer pruebas con segmentos de la secuencia de archivos haciendoconvert -fuzz 5% -delay 1x12 shot00{12..24}.png -resize 720 -layers OptimizeTransparency secuencia.gif
Esto produciría un GIF a partir de los fotogramas shot0012.png hasta el shot0024.png ignorando el resto.
Si tenéis muchos fotogramas y os sale un GIF muy lento y pesado probad a usar 1 fotograma de cada 2 haciendoconvert -fuzz 5% -delay 1x12 shot*[24680].png -resize 720 -layers OptimizeTransparency secuencia.gif
Si tenéis una animación que os gusta pero no es cíclica podéis hacer una animación tipo ping-pong (como la del zorro) haciendo convert -fuzz 5% -delay 1x12 shot00[12..24].png shot00[24..12].png -resize 720 -layers OptimizeTransparency secuencia.gif
Incluso si lo que tenéis es una secuencia de fotogramas en los que la cámara se ha movido, podéis estabilizarlos y entonces generar el GIF, lo expliqué en el apunte: Crear un gif animado estabilizando una imagen
inadyn and openSUSE Raspberry Pi
Fortunately, there's not only this service but other services too. Just for reference, here are some (not only free):
http://www.dyndns.org
http://freedns.afraid.org
http://www.zoneedit.com
http://www.no-ip.com
http://www.easydns.com
http://www.tzo.com
http://www.3322.org
http://www.dnsomatic.com
http://www.tunnelbroker.net
http://dns.he.net/
http://www.dynsip.org
http://www.sitelutions.com
http://www.dnsexit.com
http://www.changeip.com
http://www.zerigo.com
http://www.dhis.org
https://nsupdate.info
http://duckdns.org
https://www.loopia.com
https://www.namecheap.com
https://domains.google.com
https://www.ovh.com
https://www.dtdns.com
http://giradns.com
Let's see one of them https://freedns.afraid.org. After you register, go to Dynamic DNS link (on the left top box-for members).
Add your host with type A and subdomain and domain what you like as host.
Now there's going to be a list of your host names. Right click on the Direct Link and copy the link. You should keep the alpha-numeric key. The address will be something like http://freedns.afraid.org/dynamic/update.php?[alpha-numeric-key]
Now it's time to install the client. I've found it from https://github.com/troglobit/inadyn.
1. First of all, install the needed programs to build the service.
2. Then
cd inadyn
3. Download the program from ftp://troglobit.com/inadyn/
and decompress it
4. Go to the directory
5. Compile and install
make install
6. Create the confing file
with the following content
--password PASSWORD
--update_period 3600
--forced_update_period 14400
--alias HOSTNAME,alphanumeric key
--background
--dyndns_system default@freedns.afraid.org
--syslog
The bold words are the ones you should change. Remember the alphanumeric key is the one you got from right click on the Direct Link.
7. Start the client. Create the service file.
8. Add the following content.
Description=inadyn Dynamic DNS Update Client
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/sbin/inadyn
[Install]
WantedBy=multi-user.target
9. Start the service
and enable the service
10. Reboot and check if the service is running.
you should get results something like:
no-ip and openSUSE Raspberry Pi
Next step is to be sure that we can have access from outside our house (since most of the times, Raspberry Pi is located at home).
To do that we use Dynamic DNS services. A free service (so far) is No-IP. Most of the routers support it. You can use your router's service. But what if you want 2 different host names on the same IP? Let's say you have different ARM boards on the same router or you have a server etc.
1. First of all, install the needed programs to build the service (same as I did with ZNC)
2. Then
cd noip
3. Download the program
and decompress it
4. Go to the directory
5. Compile and install
make install
While it install’s the software you will prompted to enter the username & password. Once that is done it will ask you teh refresh interval … leave it.. to have the default value. You are required to answer some more questions … just ans NO an d you should be good to go.
6. Start the client
To check if the service is running, use the command:
and the results should be like
Process 1516, started as noip2, (version 2.1.9)
Using configuration from /usr/local/etc/no-ip2.conf
Last IP Address set EXTERNAL IP
Account USERNAME
configured for:
host HOSTNAME
Updating every 30 minutes via /dev/eth0 with NAT enabled.
Auto start the client on reboot
But what if you reboot? You want to start the client everytime you reboot. This can be done with systemd.
1. Create the service file.
2. Add the following content.
Description=No-IP Dynamic DNS Update Client
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/bin/noip2
[Install]
WantedBy=multi-user.target
3. Start the service
and enable the service
Create an openSUSE SD card for your Raspberry Pi B and B+
Here we'll see how to create an SD card with openSUSE. There are plenty of information at the wiki page https://en.opensuse.org/HCL:Raspberry_Pi
. I'll collect the information I need for projects I'll write next.
I used 13.1 as distro because it's easier for me to resize the SD card.
1. Download the image (openSUSE-13.1-ARM-JeOS-raspberrypi.armv7l.raw.xz) from here:
http://download.opensuse.org/repositories/devel:/ARM:/13.1:/Contrib:/RaspberryPi/images/
decompress the image.
2. Find the device name of your card
usually it's going to be /dev/mmcblk0.
and create the card (as root)
3. Since I didn't use a monitor (HDMI or DVI), I had to do some extra steps before boot my raspberry pi.
a. Delete the file /var/lib/YaST2/reconfig_system to start headless.
b. Resize the ext4 partition with Gparted.
4. When boot the Raspberry Pi, use the following
ssh root@IP
password: linux
Now the first command will be
and then update
Livros - From this moment on
Per service ulimits
In the good old days of sysvinit, if you wanted to run some extra code during start up, you were either (ab)using the sysconfig file or patching the init script itself. The init scripts in many packages are not as marked as configuration, which means in those cases your edits were lost. If it was marked as configuration then you have to merge your changes with those fixes manually. In either case … not ideal.
Apparmor and multiple instances of the same service
Getting started
Let’s say you want to have 3 instances of redis. One for each redis using app. Getting 3 instances app with systemd’s nifty Instantiated Services is easy.
[Unit]
Description=Redis
After=network.target
PartOf=redis.target
[Service]
Type=simple
User=redis
Group=redis
PrivateTmp=true
PIDFile=/var/run/redis/%i.pid
ExecStart=/usr/sbin/redis-server /etc/redis/%i.conf
Restart=on-failure
[Install]
WantedBy=multi-user.target redis.target
“systemctl start redis@discourse” will launch us an instance with “discourse.conf”. Other systemctl commands just work as fine. “systemctl enable redis@discourse” , “systemctl status redis@discourse” . Now to stop all redis instances? “systemctl stop redis.target”
Deploying Docker for OpenStack with Crowbar
A couple of months ago, I was meeting colleagues of mine working on Docker and discussing about how much effort it would be to add support for it to SUSE OpenStack Cloud. It's been something that had been requested for a long time by quite a number of people and we never really had time to look into it. To find out how difficult it would be, I started looking at it on the evening; the README confirmed it shouldn't be too hard. But of course, we use Crowbar as our deployment framework, and the manual way of setting it up is not really something we'd want to recommend. Now would it be "not too hard" or just "easy"? There was only way to know that... And guess what happened next?
It took a couple of hours (and two patches) to get this working, including the time for packaging the missing dependencies and for testing. That's one of the nice things we benefit from using Crowbar: adding new features like this is relatively straight-forward, and so we can enable people to deploy a full cloud with all of these nice small features, without requiring them to learn about all the technologies and how to deploy them. Of course this was just a first pass (using the Juno code, btw).
Fast-forward a bit, and we decided to integrate this work. Since it was not a simple proof of concept anymore, we went ahead with some more serious testing. This resulted in us backporting patches for the Juno branch, but also making Nova behave a bit better since it wasn't aware of Docker as an hypervisor. This last point is a major problem if people want to use Docker as well as KVM, Xen, VMware or Hyper-V — the multi-hypervisor support is something that really matters to us, and this issue was actually the first one that got reported to us ;-) To validate all our work, we of course asked tempest to help us and the results are pretty good (we still have some failures, but they're related to missing features like volume support).
All in all, the integration went really smoothly :-)
Oh, I forgot to mention: there's also a docker plugin for heat. It's now available with our heat packages now in the Build Service as openstack-heat-plugin-heat_docker (Kilo, Juno); I haven't played with it yet, but this post should be a good start for anyone who's curious about this plugin.
Устойчивые имена сетевых интерфейсов
Считается, что подобный подход дает больше информации, чем прибитие гвоздями имен интерфейсов eth? к MAC-адресам в 70-persistent-net.rules. Однако, не обходится без недостатков. Например, при запуске системы под гипервизором VMWare ESXi, единственный сетевой интерфейс у меня называется eno16777728. Устройства, определяемые в DTB для одноплатных компьютеров на базе ARM, не поддерживаются схемой именования и имеют обычные имена eth?. А при подключении USB устройств, типа мобильных телефонов или модемов, схема именования генерирует скорее неустойчивые имена, потому-что в имя входит расположение устройства на шине USB, которое изменится при следующем подключении, таким образом придется настраивать интерфейс заново, потому-что предыдущие сохраненные настройки будут относиться к интерфейсу с другим именем.
К счастью, udev заполняет переменную ID_NET_NAME_MAC, представляющую имя интерфейса, основанное исключительно на его MAC-адресе. По-умолчанию, эта переменная не используется, но можно поменять стандартное поведение для USB-устройств. Один способ - через настройку udev, второй - используя systemd.link, файл, используемый systemd, для конфигурации сетевых интерфейсов.
Создадим файл /etc/systemd/network/90-usb.link следуя инструкции:
[Match]Юнит-файл состоит из двух секций: [Match] для описания устройств к которым он относится и [Link] для описания того, что с ними делать. В примере выше мы просим systemd использовать политику именования основанную на MAC-адресах для всех устройств подключенных через USB. После выполнения systemctl daemon-reload можно подключить устройство и увидеть его интерфейс с именем enx112233445566. Достаточно длинное, но уникальное (в известных пределах) и не изменится при следующем подключении устройства.
Path=*-usb-*
[Link]
NamePolicy=mac
Кроме изменения имени через systemd.link можно настроить WOL, MTU, ограничить скорость на интерфейсе, назначить устройству другой MAC-адрес.

