Пару дней назад вышло ядро 4.7. В связи с этим наш репозиторий Tumbleweed в скором будущем будет обновлен. Для тех же, кому по той или иной причине нужны самые свежие версии ядер, собраные для openSUSE (не только Tumbleweed), существует специальный kernel-репозиторий. Там лежат ядра, собранные сразу же после официального релиза (в тот же день). Доступны сборки не только для x86, но и для ARM и Power. Есть vanilla.

Установка не предствляет из себя ничего сложного – самое обычное обновление rpm-пакета.
Я только что обновил ядро на одной из своих тестовых систем. Это 32-битный x86 нетбук c установленной (где-то в середине июня) Tumbleweed.

# uname -pr
4.6.2-1-pae i686

# zypper ar -f http://download.opensuse.org/repositories/Kernel:/HEAD/standard/Kernel:HEAD.repo                                                               
Adding repository 'Kernel builds for branch master (standard)' ...............................[done]
Repository 'Kernel builds for branch master (standard)' successfully added                                                                                                         
Enabled     : Yes                                                                                                                                                                  
Autorefresh : Yes                                                             
GPG Check   : Yes                                                             
Priority    : 99                                                              
URI         : http://download.opensuse.org/repositories/Kernel:/HEAD/standard/


# zypper lr
# | Alias               | Name                                       | Enabled | GPG Check | Refresh
--+---------------------+--------------------------------------------+---------+-----------+--------
1 | Kernel_HEAD         | Kernel builds for branch master (standard) | Yes     | ( p) Yes  | Yes    
2 | openSUSE-20160613-0 | openSUSE-20160613-0                        | No      | ----      | Yes    
3 | packman             | packman                                    | Yes     | (r ) Yes  | Yes    
4 | repo-debug          | openSUSE-Tumbleweed-Debug                  | No      | ----      | Yes    
5 | repo-non-oss        | openSUSE-Tumbleweed-Non-Oss                | Yes     | (r ) Yes  | Yes    
6 | repo-oss            | openSUSE-Tumbleweed-Oss                    | Yes     | (r ) Yes  | Yes    
7 | repo-source         | openSUSE-Tumbleweed-Source                 | No      | ----      | Yes    
8 | repo-update         | openSUSE-Tumbleweed-Update                 | Yes     | (r ) Yes  | Yes

Значит новый репозиторий называется Kernel_HEAD. Хорошо, я хочу обновиться только из него:

# zypper dup -r Kernel_HEAD
Retrieving repository 'Kernel builds for branch master (standard)' metadata --------------------[\]

New repository or package signing key received:

  Repository:       Kernel builds for branch master (standard)    
  Key Name:         Kernel OBS Project 
  Key Fingerprint:  4529410A B52F94C4 03BAB484 ECEEF210 03579C1D  
  Key Created:      Mi 22 Apr 2015 14:25:51 CEST                  
  Key Expires:      Fr 30 Jun 2017 14:25:51 CEST                  
  Rpm Name:         gpg-pubkey-03579c1d-5537934f                  


Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): a
Retrieving repository 'Kernel builds for branch master (standard)' metadata ...................[done]
Building repository 'Kernel builds for branch master (standard)' cache ........................[done]
Loading repository data...
Reading installed packages...
Computing distribution upgrade...

The following 2 NEW packages are going to be installed:
  kernel-default-4.7.rc7-2.1.g152f160 kernel-pae-4.7.0-1.1.g24f30d5

The following 2 packages are going to be upgraded:
  kernel-firmware ucode-amd

The following 2 packages are going to change vendor:
  kernel-firmware  openSUSE -> obs://build.opensuse.org/Kernel
  ucode-amd        openSUSE -> obs://build.opensuse.org/Kernel


2 packages to upgrade, 2 new, 2  to change vendor.
Overall download size: 156.5 MiB. Already cached: 0 B.
After the operation, additional 372.8 MiB will be used.
Continue? [y/n/? shows all options] (y): y

После установки просто перезагружаемся и наслаждаемся работой нового ядра.

> uname -pr
4.7.0-1.g24f30d5-pae i686

Обновляя ядра, вы не только становитесь привлекательнее для девушек, но и помогаете проекту в качестве beta-тестера. Помните, что Tumbleweed это не самое-самое свежее ПО. Это коллекция уже протестированных вместе компонентов.
“Стоит ли мне учавстовать в этом? А вдруг я себе что-то сломаю?”, – подумает ленивец. Нет, вероятность того, что произойдет креш системы очень мал. Прежде чем ядро официально выпустят, оно пройдет серию тестов.
Если креш все же произошел, всегда можно загрузить старое ядро, в котором вы работали прежде (и где все работало). В этом случае вы очень поможете, если не поленитесь сообщить нам о возникшей проблеме.
Посмотреть список установленных ядер можно вот так:

# zypper se -si 'kernel*'
Loading repository data...
Reading installed packages...

S | Name            | Type    | Version              | Arch   | Repository                                
--+-----------------+---------+----------------------+--------+---------------------------------------
i | kernel-default  | package | 4.6.2-1.2            | i586   | (System Packages)                         
i | kernel-default  | package | 4.7.rc7-2.1.g152f160 | i586   | Kernel builds for branch master 
i | kernel-firmware | package | 20160712-137.1       | noarch | Kernel builds for branch master 
i | kernel-pae      | package | 4.6.2-1.2            | i686   | (System Packages)                         
i | kernel-pae      | package | 4.7.0-1.1.g24f30d5   | i686   | Kernel builds for branch master 

Как видете, старое ядро никуда не делось. Я отправляю всех интересующихся к 12 главе нашего руководства. Там описана Multiple Kernel магия для zypper.

Обновившись, я протестировал сейчас, к примеру, LUKS и совместимость с проприетарным broadcom модулем для wireless. Все работает как и прежде, значит я иду дальше – перехожу к обновлению на своих ARM embedded-системах, чтобы удостовериться, что и там все работает как надо. Счастливо

After upgrading my home NAS server, reinstalling FreeBSD and changing a bit the configuration of my services running on this machine, I wanted to reconfigure my notification system to receive periodic emails about the status of zfs, security, and so on. So, here is just a quick tutorial how to configure smartd, zfs-periodic (to take zfs snapshots hourly/daily/...) and OpenSMTPD to forward all the emails which are sent to the local "root" account to my gmail email address.

• FreeBSD 10.3

# uname -a
FreeBSD nas.home 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 02:10:02 UTC 2016     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

• install Smartmontools package

# pkg install smartmontools

• enable it at boot time (you can also use sysrc command to edit your rc.conf file)

# echo 'smartd_enable="YES"' >> /etc/rc.conf

• we need to create the config file

# cp /usr/local/etc/smartd.conf.sample /usr/local/etc/smartd.conf

• and activate the daily check (you can find your devices using dmesg)

# echo 'daily_status_smart_devices="/dev/ada0 /dev/ada1 /dev/ada2 /dev/ada3 /dev/ada4”' >> /etc/periodic.conf

ZFS snapshot automation tools

There are different packages which can work for you, for example: sysutils/zfs-snapshot-mgmt, sysutils/zfsnap, sysutils/zfstools. But I am using since 2009 sysutils/zfs-periodic and was working really nice for me so I don't see any point to change it.

• install the package

# pkg install zfs-periodic

• add to /etc/periodic.conf

hourly_output="root"
hourly_show_success="NO"
hourly_show_info="YES"
hourly_show_badconfig="NO"
hourly_zfs_snapshot_enable="YES"
hourly_zfs_snapshot_pools="YOUR-POOL-NAME"
hourly_zfs_snapshot_keep=4
daily_zfs_snapshot_enable="YES"
daily_zfs_snapshot_pools="YOUR-POOL-NAME"
daily_zfs_snapshot_keep=7
weekly_zfs_snapshot_enable="YES"
weekly_zfs_snapshot_pools="YOUR-POOL-NAME"
weekly_zfs_snapshot_keep=5
monthly_zfs_snapshot_enable="YES"
monthly_zfs_snapshot_pools="YOUR-POOL-NAME"
monthly_zfs_snapshot_keep=2

This configuration should be enough and should work, is really simple, but here are some additional things I added to my /etc/periodic.conf file (for next entries you don't need zfs-periodic to be installed, they are part of FreeBSD):

# check ZFS
daily_status_zfs_enable="YES"
# list ZFS pools
daily_status_zfs_zpool_list_enable="YES"
# enable daily ZFS scrub
daily_scrub_zfs_enable="YES"
# empty string selects all pools
daily_scrub_zfs_pools="POOL1 POOL2"
# days between scrubs
daily_scrub_zfs_default_threshold=“7"
# check ports for security issues
daily_status_security_portaudit_enable="YES"

There are many useful things which you can add, for more check /etc/default/periodic.conf file.

Now, all these notifications from periodic will be emailed to the local root account. I prefer to have them forwarded to my gmail account. So here is how I did it. I used OpenSMTPD which is an implementation of the server-side SMTP protocol. Yes, Sendmail is coming as default with FreeBSD but I disabled it. I used it for many years, some years ago, but these days I prefer to work with Postfix.

• first we need to stop the sendmail service which is running by default

# service sendmail stop
Stopping sendmail.
Waiting for PIDS: 741.
sendmail_submit not running? (check /var/run/sendmail.pid).
Stopping sendmail_msp_queue.
Waiting for PIDS: 744.

• and disable sendmail at boot (we don't want it to run again after a restart). Add to your /etc/rc.conf

# Disable Sendmail MTA
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

• let's install the OpenSMTPD package

# pkg install opensmtpd
New packages to be INSTALLED:
    opensmtpd: 5.9.2p1_1,1

    [...SKIP...]

    If you are upgrading from OpenSMTPD version 5.7.3 or earlier, please
    follow the procedure below to update the permissions on the OpenSMTPD
    spool directories:

      1. Stop 'smtpd' service:

         # /usr/local/sbin/smtpctl stop

      2. Update permissions:

         # chown -R _smtpq:wheel /var/spool/smtpd/corrupt
         # chown -R root:_smtpq /var/spool/smtpd/offline
         # chown -R _smtpq:wheel /var/spool/smtpd/purge
         # chown -R _smtpq:wheel /var/spool/smtpd/queue
         # chown -R _smtpq:wheel /var/spool/smtpd/temporary
         # chmod -R 770 /var/spool/smtpd/offline
         # chmod -R 700 /var/spool/smtpd/purge

      3. Start 'smtpd' service:

         # service smtpd start

We don’t upgrade a previous installed version so we can just ignore the above message

• enable it at boot (add to /etc/rc.conf)

# OpenSMTPD
smtpd_enable="YES"

Let’s try to configure OpenSMTPD.

# cp /etc/mail/aliases /usr/local/etc/mail/aliases

• uncomment the root line in /usr/local/etc/mail/aliases to have it like this

# Pretty much everything else in this file points to "root", so
# you would do well in either reading root's mailbox or forwarding
# root's email from here.

 root:  GMAIL-USERNAME@gmail.com

• create a "secrets" file in /usr/local/etc/mail/ with the content

credentials GMAIL-USERNAME:GMAIL-PASSWORD

• now we have to generate the aliases and secrets db to be used in opensmtpd config file:

# cd /usr/local/etc/mail/
# /usr/local/libexec/opensmtpd/makemap aliases
# /usr/local/libexec/opensmtpd/makemap secrets

• let’s see if the db files were created:

# pwd
/usr/local/etc/mail
# ls -ltr *.db
-rw-r--r--  1 root  wheel  131072 Jul 16 19:36 secrets.db
-rw-r--r--  1 root  wheel  131072 Jul 16 19:37 aliases.db

• now we need a config file for opensmtpd /usr/local/etc/mail/smtpd.conf. Here is the content

listen on 127.0.0.1

table aliases db:/usr/local/etc/mail/aliases.db
table secrets db:/usr/local/etc/mail/secrets.db

accept for local alias <aliases> deliver to mbox

accept for any relay via tls+auth://credentials@smtp.gmail.com:587 auth <secrets> as GMAIL-USER@gmail.com

• let’s start once OpenSMTPD (we already added it to /etc/rc.conf to start automatically after restart)

# service smtpd start
Performing sanity check on smtpd configuration:
configuration OK
Starting smtpd.

• check to see if the service is listening to port 25

# netstat -an | grep LIST
tcp4       0      0 127.0.0.1.25           *.*                    LISTEN
tcp6       0      0 ::1.25                 *.*                    LISTEN

• now, let’s send a test email to local root account to see if it will be forwarded to my gmail email address: GMAIL-USER@gmail.com

# echo "This is a test" | mail -s "Testing OpenSTPD" root

• if we check the log files, we will see that the email was sent, indeed

# tail -f /var/log/maillog
Jul 16 19:41:21 nas smtpd[78403]: smtp-in: Closing session 67c64e075759c7af
Jul 16 19:41:21 nas smtpd[78403]: smtp-out: Connecting to tls://74.125.136.xxx:587 (ea-in-f109.1exxx.net) on session 67c64e105d261179...
Jul 16 19:41:21 nas smtpd[78403]: smtp-out: Connected on session 67c64e105d261179
Jul 16 19:41:22 nas smtpd[78403]: smtp-out: Started TLS on session 67c64e105d261179: version=TLSv1.2, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128
Jul 16 19:41:22 nas smtpd[78403]: smtp-out: Server certificate verification succeeded on session 67c64e105d261179
Jul 16 19:41:23 nas smtpd[78403]: relay: Ok for d7ace5ca896de069: session=67c64e105d261179, from=<GMAIL-USER@gmail.com>, to=<GMAIL-USER@gmail.com>, rcpt=<root@nas.home>, source=192.168.0.20, relay=74.125.136.109 (ea-in-f109.1exxx.net), delay=2s, stat=250 2.0.0 OK 1468698419 z5sm4117476wme.5 - gsmtp
Jul 16 19:41:33 nas smtpd[78403]: smtp-out: Closing session 67c64e105d261179: 1 message sent.

It seems that everything is working, so we are done!!!

I made Geeko biscuits with the biscuits cutter 3D printed I was given the last day of the openSUSE conference.

Here there are the biscuits before cooking then:

And the final result:

I have to say that as the cutter has such a complex shape it is quite difficult to use, but the biscuits are so cute that it is worthwhile!! I’ll try with a different recipe next time, maybe it will get easier

Ya me pasó hace tiempo, que quería descargar varias decenas de archivos adjuntos a otros tantos emails y no sabía como sin pasarme la mañana moviendo el ratón por la pantalla. Entonces lo solucioné con IMAP, montando el correo electrónico de GMAIL como una carpeta local de mi ordenador pude obtener una copia en disco duro de los emails y sus adjuntos. Ahora se repite, misma situación, solución diferente.

Esta vez he optado por otra solución, requiere menos trabajo y es mucho más rápida que esperar a tener una copia local de GMAIL para extraer archivos, xdotool: un comando de consola que replica los movimientos de ratón y teclado, eventos de click, click-derecho, pulsación de teclas, etc… De esta manera es sumamente fácil simular que movemos el ratón al tal sitio, cliqueamos un botón, movemos a otro, pulsamos ENTER… ad infinitum…

while [ true ]; do xdotool search "Correo" windowactivate --sync mousemove --window %1 290 460 sleep 0.5 click 1 sleep 3 key KP_Enter sleep 1 mousemove 1264 250 sleep 1 click 1 sleep 4; done

La siguiente línea de texto hace eso, sobre una página de GMAIL:
-busca la ventana llamada “Correo” y le da el foco activándola
– usandola como referencia mueve el ratón a sus coordenadas relativas 290×460 (botón descargar adjunto)
– espera 0.5 segundos y cliquea botón izquierdo del ratón (click 1)
– espera 3 segundos (mientras se abre diálogo guardar adjunto)
– pulsa ENTER
– espera 1 segundo (la descarga es rápida)
– mueve el ratón al botón “Siguiente mensaje”
– espera 1 segundo
– pulsa botón izquierdo del ratón
– espera 4 segundos a que cargue siguiente mensaje.
– repetir.

Ni os cuento las risas que nos hemos echado en algún trabajo a cuenta de automatizar el movimiento del ratón y dejar durante horas al 3DStudio modelando el solito escenarios… o dejando al ordenador durante largos periodos de tiempo enviando insultos por mensajería mientras nosotros nos íbamos de coartada a almorzar a la cafetería.

24 июня, во время openSUSE Conference 2016, Norman Fraser (Chief Executive Officer из компании SoftIron Ltd.) представил новую aarch64 серверную out-of-the-box систему. Overdrive 1000 привлек внимание многих и не только потому, что она продается с предустановленной openSUSE. По словам Нормана, это тчательно продуманная 64-битная ARM® developer-система с AMD Opteron A1100 процессором. Многие разработчики хотят больше, чем могут предложить обычные development-board embedded системы. Все помнят обсуждение ARM как десктопной архитектуры после LinuxCon Europe в конце прошлого года.
Overdrive 1000 продается с openSUSE Leap 42.1, где уже установленны Apache Web-сервер, MySQL, PHP, Xen, KVM, Docker и openJDK. Таким образом, пользователи могут приступать к работе сразу же после загрузки ОС. Напомню, что для aarch64 существуют установочные образу практически для всех известных дистрибутивов. Пользователи tumbleweed, к примеру, могут скачать установочные образы отсюда.

Overdrive 1000 стоит всего $599. За эти деньги мы получаем:

• Processor cores 4 x 64-bit ARM Cortex A57 Cores
• 2 x RDIMM with 8GB DDR4 DRAM (можно увеличить до 64 GB)
• 1 x 1GBase-T Ethernet
• 2 x USB 3.0 ports
• 2 x SATA 3.0 ports
• 1 x 1TB HDD
• Wirespeed 1Gbps throughput
• Low and predictable energy consumption at 45 watts max

Собираюсь ли я заказывать эту систему? Однозначно ДА! Docker уже поддерживает aarch64 (раз, два), а это был пожалуй единственный вопрос, который меня беспокоил. Пока я работал только с 32-битными ARM системами, пора переходить на 64

Новичков в openSUSE вводит в заблуждение настройка сети из-за того, что для её управления существует несколько независимых технологий. В openSUSE Tumbleweed сегодня используется NetworkManager и wicked. Первый используется по умолчанию. Если же вам, к примеру, понадобится добавить статический маршрут и вы спросите об этом гугл, скорее всего в первую очередь вы найтдете классический способ сделать это. Помние, этот способ не сработает, если вы используете NM, и наоборот. Также не стоит забывать, что настройки сети в разных дистрибутивах могут отличаться.

Добавить маршрут можно с помощью команды route. В данном примере для доступа в сеть 172.19.0.0/16 я использую рутер 172.20.1.161. Тут стоит помнить лишь о том, что эти настройки пропадут после перезагрузки.

# route add -net 172.19.0.0 netmask 255.255.0.0 gw 172.20.1.161

Чтобы настройки не пропали, нужно прописать их в конфиге NM. Для каждого соединения существуют свои настройки. Загляните в каталог /etc/NetworkManager/system-connections. Там находится список файлов, каждый из которых относиться к тому или иному соединению. Чтобы добавить route правило, о котором я говорил выше, просто добавьте такую строчку в секцию [ipv4]:

route0=172.19.0.0/16;172.20.1.161

Если вы используете KDE Workspace, вы можете добавить эти настройки в KDE NM-апплете. Для этого просто правый клик на иконке, выбираем “Configure Network Connections…”

Появляется список соедининий. Выбираем нужное нам, нажимаем “Edit”. В появившемся окне переходим во вкладку IPv4 и там нажимаем “Routes…”, где можно добавить новые или удалить старые маршруты.

Polyglot project aims to provide the summary of various choices available for each of the components while developing a web application. It details their strengths so that one can easily choose the right component to build a great solution.

I had gone through several blogs, stack-overflow/quora answers to choose a proper database, programming language, web-framework etc. to build a solution in the past. Most of them were out-dated and I had to keep track of the date for each of the posts.

So for this HACKFEST 2016, wondered how would it be if we could share the learning through a wiki and collaboratively maintain an up-to-date content. I had a hunch that this might be a problem that many would have faced and would be good to solve.

It starts with Questions/Concerns one should keep in mind before starting a project. It goes deep enough, providing a Syntax Cheat Sheet so that one can use it to directly shift the mind from one language to another by going through a single page. It also lists various WebFrameWorks and several Programming Language choices. Am a big fan of Rails and GoLang. The idea is a work in progress..

The wiki is available on github!! It would be nice to collaborate and make it better

Maintenance and security updates for the stable openSUSE Leap releases are automatically tested using OpenQA, and also receive community testing prior to release. In addition, many updates to openSUSE Leap are inherited from SUSE’s enterprise products, where they already receive thorough review, and automated as well as manual testing.

Should anything go wrong, here is how to “uninstall” an online update using zypper.

zypper in --oldpackage ` \
zypper info -t patch --conflicts openSUSE-2016-XXX | \
grep " < " | while read NAME C VERSION; do \
rpm --quiet -q --queryformat "%{name}\n" $NAME && echo "${NAME}<${VERSION}"; \
done`

Replace openSUSE-2016-XXX with the update in question. All involved packages are installed in a prior version. This, of course, is an alternative to using Btrfs snapshots. Note that the update will be offered again.

If you want to help review proposed online updates, just check the “untested updates” repo in YaST or add one of the -test repositories to receive updates early.

dd if=/dev/zero of=wxp.img bs=1M seek=10240 count=0
fdisk -c=dos wxp.img # resize partition, activate(!)
losetup -Pf wxp.img
ntfsresize /dev/loop0p1
losetup -d /dev/loop0

So Hackweek 14 is over. It started during the openSUSE Conference 2016 on Friday June 24 and continued all over the following week.

I had worked on integrating snapshots with Salt with Pablo just some weeks before that and I was waiting for the openSUSE Conference to get the chance to show Thomas what we had done in order to get feedback and figure out next steps.

A few days before the Conference Redhat did a press release that caught my attention: a framework to build container images with Ansible. Yes, that makes a lot of sense. My head started immediately to think all day long about the challenges to build something like that: Installing the configuration management tool without leaving it there, etc. I got curious and started poking at the README.

On one hand, it was not what I was expecting (well, at least, for a Press Release or Tech Preview). It still “generated” Dockerfiles, relied on Ansible to be installed in some way, wich was “templated” into Dockerfiles, and it was of course a new tool.

On the other hand, it was pure inspiration: I remembered why I like Salt so much. I knew that with Salt I wouldn’t need to build a “new tool”. I’d only need to write a module and connect some pieces, and that makes my feature distributed, accessible, deployable, etc. I’d not need to interact with Docker directly, but only with the Salt execution module for it. The best part: I had a Hackweek project!.

I used the chance that Thomas was at the openSUSE Conference to ask him some details about salt-thin and explain him rough ideas.

The feature went more or less like expected:

• A Docker image is basically another image, modified.
• The problem can be reduced to run a Salt state run inside of the container, modulo problems.
  • The image does not have Salt.
  • After the State run, we can’t leave Salt there.
  • The container does not have connectivity with the Salt master.
  • Pillars may be templated against grains which come from the container.

After tackling the problems one by one, you can factor some stuff out:

• If dockerng.build_sls needs to apply state on a new container and commit it, why not allow to call state on a running container?. dockerng.sls was born.
• If we are going to call state.sls and grains.items on the container, why not allow to call any module in a container?. dockerng.call was born.

On Friday I was able to give the following Lightning Talk:

The result is:

• You can build images using your own salt:// tree modules only needing Python on the base image. And yes, you can consume pillar data.
• You can execute modules on containers. Which will be interesting to see how it can be used for auditing (eg. HubbleStack).

I prepared a pull request, which had the best reception I ever got on a pull request:

There are some details to polish and I hope it can be merged soon.