Заставить работать wine в centos 7

Это блин жестокий квест…

По умолчанию пакет wine в centos собран как 64 битный. А большинство приложений для винды 32-х битные. Вот оне и не запускаются.
Производитель дистрибутива (не будет тыкать в него пальцем, но все понимают, что это RedHat) отказывается поставлять 32-х битный wine. Принципиально.

И вот тем, кто решил использовать в качестве рабочего стола CentOS 7 придется пройти квест по сборке и установке 32-х битного wine, описанный вот тут. Я как раз сейчас этим занимаюсь.

Апдейт.
Ну да, в руководстве был показан верный вектор. Но как всегда — «дьявол кроется в деталях».
Из-за того, что сейчас на сайте находится более свежая версия wine, чем показана в мануале, у нее малость другой spec файл. Поэтому, для версии wine-1.7.53-1.el7.src.rpm diff будет выглядеть следующим образом:

# diff wine.spec wine.spec.2 
372,373c372,373
< Requires:       wine-core = %{version}-%{release}
< Requires:       wine-common = %{version}-%{release}

> #Requires:       wine-core = %{version}-%{release}
> #Requires:       wine-common = %{version}-%{release}
375a376
> Requires: wine-core(x86-32) = %{version}-%{release}
702c703


> sed -i ‘/winegcc/s/-o /-m32 &/’ tools/makedep.c

И да, в процессе надо включать мозги, понимая, что имена файлов даются для Сайнтифик линукса. После создания каких либо rpm надо сначала поглядеть как они в результате называются в CentOS. И только потом выполнять рекомендуемые команды.

Ubuntu падает, падает, падает…

Запуск Тандерберда валит в корку X сервер в Ubuntu.
Завтра буду менять Ubuntu на что нибудь другое.

Ubuntu продолжает «радовать»

В Тандерберде нажимаешь кнопку ответить и… падает X сервер.
Миленько так.

Первый глюк новой Ubuntu

Меня спрашивали, почему я Ubuntu тока на рабочей станции держу.
Да вот по этому самому :0) Обновился, гарантированно получил глюки. Вот и сейчас, ничего не изменилось. Хотя, конечно это не LTS, но все равно не приятно.
Оно мне надо? В RedHat (CentOS) я обновляюсь спокойно 🙂

Mikrotik VPLS

Пытался построить VPLS на микротике (Cloud Hosted Router) в VirtualBox. Не получилось, есть подозрение, что Virtual Box малость неправильно эмулирует ethernet интерфейсы.

Собрал сетку на живых 450G устройствах. Все заработало на ура. L2 VPN фунциклирует как часы.

На выходных попробую в vmware повторить эксперимент.

Vbox и Cloud Hosted Router

Что то  Cloud Hosted Router в Virtual Box странно работает.
Сетевые интерфейсы через раз поднимаются 🙁
Надо будет в vmware попробовать его погонять.

MUM Москва

Вчера побывал на MUM в Москве.

Было (по заявлению Микротик) ~750 участников.

Узнал, что Mirotik сделал специальный образ для виртуальных машин Cloud Hosted Router, на который не надо покупать лицензию. Правда с вшитым ограничением скорости на интерфейсе. Для снятия ограничения лицензию таки придется покупать, но они обещают, что цена на нее будет меньше. Теперь крутить RouterOS в виртуалках будет проще.

Слушал все выступления. В каждом было что то интересное.
Вообщем походом удовлетворен.

Puppet

Puppet прикольный. Если разворачивать однотипные конфигурации на большом количестве серверов, его использование дает ощутимый профит. Я думаю, что для разруливания основных вопросов вполне можно обойтись без скриптописания на ruby. Во всяком случае я пока не нашел для чего бы мне понадобилось написание пупет скриптов. Хотя… если их кто то пишет  — значит это кому то нужно :).
Но это жутко опасная штука. Очень опасная.

Лопата в руках + puppet (iptables)

После настройки DNS надо подумать о настройке fierwall на серверах.

Точно так же, как и с DNS, существуют модули puppet, предназначенные для управления fierwall. Исходя из соображения, зачем использовать сторонние обёртки, когда iptables сам по себе крут и админ должен знать его на Ять, я не буду использовать эти модули.

Что будем делать:

  • Удалим firewalld, поставим классический iptables-service.
  • Создадим файл с конфигурацией фаервола, в стиле /etc/sysconfig/iptables.
  • На клиенте запустим скрипт, который применит правила fierwall.

На puppet сервере, создадим файл с конфигурацией firewall для машины с dns:
# cd /var/puppet/centos7-2.test.local/etc/
# mkdir sysconfig
# vim sysconfig/iptables
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state —state NEW -m tcp —dport 22 -j ACCEPT
-A INPUT -p udp -m state —state NEW -m udp —dport 53 -j ACCEPT
-A INPUT -p tcp -m state —state NEW -m tcp —dport 53 -j ACCEPT
COMMIT

В файле site.pp добавляем новый класс.
class minimal-iptables {
# Удаляем firewalld
package { ‘firewalld’:
ensure => absent,
  before => Package[‘iptables-services‘]
}
# Перед удалением firewalld останавливаем соответствующий
# сервис и делаем ему disable.
service { ‘firewalld’:
name => «firewalld»,
enable => false,
ensure => stopped,
before => Package[‘firewalld’]
}
# Устанавливаем iptables-services
package { ‘iptables-services’ :
ensure => installed
}
service { ‘iptables’:
  enable => true,
ensure => running,
  require => Package[«iptables-services»]
 }
# Определяем файл, в котором будем описывать
# правила firewall
file { ‘/etc/sysconfig/iptables’:
ensure => file,
mode => ‘0600’,
owner => ‘root’,
# Для каждой машины предполагается свой файл
source => «puppet:///configs/$fqdn/etc/sysconfig/iptables»,
require => Package[«iptables-services»]
}
# Описываем программу, которая будет выполняться
# на машине для поднятия правил fierwall
exec { ‘firewall’:
# «Подписываемся» на файл
subscribe => File[«/etc/sysconfig/iptables»],
# Устанавливаем правила фаервола из файла.
command => «/usr/bin/cat /etc/sysconfig/iptables | /usr/sbin/iptables-restore «,
# Говорим, что программа будет выполняться
# только если файл, на который мы подписаны,
# изменился.
refreshonly => true
}
}

Вносим изменения в node.
node ‘centos7-2.test.local’ {
include ‘baselinux’
include ‘minimal-iptables’
include ‘dns’
}

Проверяем файл манифеста.
# puppet parser validate /etc/puppet/manifests/site.pp

У данного способа есть недостаток — при исполнении скрипта будут рваться сессии. Это можно обойти, используя вместо файла /etc/sysconfig/iptables самописанный скрипт.

Лопата в руках + puppet (bind)

На виртуалке centos7-2 будем поднимать DNS сервер.

Я долго думал, использовать ли для управления DNS сервером скрипты из PuppetForge (https://forge.puppetlabs.com/)? Или держать на puppet сервере файлы конфигурации bind и рулить удаленным сервером изменяя эти файлы.

Победил второй путь. Я прекрасно умею управлять DNS сервером при помощи его конфигурационых файлов и файлов зон. Учить дополнительную обертку, написанную сторонними компаниями, на неизвестном мне ruby… Зачем так усложнять?

Поэтому, буду использовать конфигурационные файлы и тупо копировать их на машину с DNS сервером.

Создадим директорию /var/puppet.
# mkdir /var/puppet

В которой будут директории, содержащие конфигурационные файлы для отдельных машин.
# mkdir /var/puppet/centos7-2.test.local
# cd /var/puppet/centos7-2.test.local
# mkdir etc
# mkdir -p var/named/slaves

В новой директории etc разместим файл named.conf. Возьмем стандартный файл и внесем в него некоторые изменения. Не буду приводить тут весь файл, только измененные и добавленные строки.
listen-on port 53 { any; };
listen-on-v6 port 53 { none; };
allow-query     { any; };
dnssec-enable no;
dnssec-validation no;
zone «test.local» IN {
type master;
file «test.local»;
allow-update { none; };
allow-query { any; };
allow-transfer { none; };
};
zone «200.168.192.in-addr.arpa» IN {
type master;
file «200.168.192»;
allow-update { none; };
allow-query { any; };
allow-transfer { none; };
};

В директории var/named создадим два файла описания зон
# cat var/named/test.local 
$TTL 86400 ; 1 day
test.local. IN SOA post.test.local. artur.test.local. (
2015091701 ; serial
10800      ; refresh (3 hours)
3600       ; retry (1 hour)
604800     ; expire (1 week)
86400      ; minimum (1 day)
)
NS centos7-2.test.local.
MX 10 post.test.local.
TXT «v=spf1 mx -all»
SPF «v=spf1 mx -all»

artur-office A 192.168.200.1
post A 192.168.200.97
centos7-2 A 192.168.200.98
centos7-1 A 192.168.200.99

# cat var/named/200.168.192 
$TTL 86400 ; 1 day
200.168.192.in-addr.arpa. IN SOA post.test.local. artur.test.local. (
2015091701 ; serial
10800      ; refresh (3 hours)
3600       ; retry (1 hour)
604800     ; expire (1 week)
86400      ; minimum (1 day)
)
NS centos7-2.test.local.

99 IN PTR centos7-1.test.local.
98 IN PTR centos7-2.test.local.
97 IN PTR post.test.local.
1 IN PTR artur-office.test.local.

Проверкой синтаксиса мы должны заниматься сами. Поэтому:
# named-checkconf etc/named.conf
# named-checkzone test.local var/named/test.local 
zone test.local/IN: loaded serial 2015091701
OK
 # named-checkzone 200.168.192.in-addr.arpa var/named/200.168.192 
zone 200.168.192.in-addr.arpa/IN: loaded serial 2015091701
OK

Теперь необходимо что бы файловый сервер puppet узнал про нашу директорию с файлами.
# vim /etc/puppet/fileserver.conf
[configs]
        path /var/puppet
        allow *

Перезапустим сервер:
# systemctl restart puppetmaster

Внесем изменения в файл манифест site.pp. Сначала добавим новый класс.
class dns {
# для работы необходим пакет bind
    package { ‘bind’:
                ensure => installed
    }
    include ‘stdlib’
    # Отключим ipv6 у bind.
    # Для этого надо при запуске демона передать ему
    # параметр -4. Добавим соответствующую строку в
    # конфигурационный файл.
    file_line { ‘named_no_ipv6’:
        path => ‘/etc/sysconfig/named’,
        line => ‘OPTIONS=»-4″‘
    }
    # Конфигурационный файл демона
    file { «/etc/named.conf» :
        ensure => file,
        mode => ‘0640’,
# Путь к файлу на файловом сервере
# Я специально присвоил директории имя такое
        # же как и имя машины.
# Теперь можно пользоваться переменной $fqdn
# И если у нас появится другой DNS сервер,
        # то благодаря этой переменной
# мы спокойно разрулим кому какие конфиги
        # отдавать.
        source => «puppet:///configs/$fqdn/etc/named.conf»,
        require => Package[«bind»],
# После изменения файла сделаем reload 
        # серверу bind
        notify  => Service[«named»]
    }
    file { «/var/named» :
        path => «/var/named»,
        mode => ‘0640’,
        group => ‘named’,
        source => «puppet:///configs/$fqdn/var/named»,
# Тут у нас передается содержимое директории
        ensure => directory,
# Говорим, что бы передавались все файлы и
        # поддиректории.
# Вместо remote можно использовать true. 
        # Тогда в целевой директории будут удаляться
        # все файлы, которые отсутствуют в директории
        # шаблоне.
# Поскольку делал по быстрому, пока оставлю
        # так. Но в дальнейшем надо будет привести 
        # все в порядок.
        recurse => remote,
        sourceselect => all,
        require => Package[«bind»],
        notify  => Service[«named»]
    }
    service { ‘named’:
        enable => true,
        ensure => running,
        require => Package[«bind»]
    }
}

Ну и изменим соответствующую ноду.
node ‘centos7-2.test.local’ {
    include ‘baselinux’
    include ‘dns’
}

Пока остановимся. Останется только разрулить правила фаервола.