Сравнение Macbook Pro 13 2017 и Macbook Air 13 2015

Чуть больше года назад купил Macbook Air 13 2015, RAM 8GB, SSD 256GB.

Всё мне в этом макбуке нравилось кроме экрана и дело даже не в разрешении, а в углах обзора — стоило хоть немного отклониться от идеального угла, как изображение становилось малочитаемым. Это очень раздражало, постоянно приходилось поправлять угол наклона дисплея. А ещё сильно раздражала очень низкая скорость обновления пикселей или время отклика, особенно это бросалось в глаза при прокрутке страниц — всё расплывалось, точнее размазывалось.

Ждал выхода нового макбука и дождался такого, что без ругательств сложно описать, ну вы сами знаете. Решил купить Macbook Pro 13 2015, но найти его в продаже сложно, вероятно мне надо было реагировать быстрее, может быть и успел бы. Сейчас же старую модель можно купить разве что без русских букв, да и не особо она и подешевела — 86 тысяч рублей против 95 тысяч за младший новый макбук про. Короче говоря, мучился я, мучился и решил, что придётся попробовать новый макбук. Остановился на самой доступной — Macbook Pro 13 2017 RAM 8GB, SSD 256GB.

Лично меня в новых макбуках пугает не отсутствие нормальных разъёмов, не наличие всего двух USB-C (в младшей версии), а странная, плоская клавиатура, особенно блок управления курсором. Кстати, я не пояснил для каких целей я использую макбук. Я — сисадмин, причём основной метод удалённого управления оборудованием это текстовая консоль. Поэтому для меня важнее всего именно клавиатура, не процессор, не память и даже не жёсткий диск. Важен именно рельеф клавиатуры, который позволяет нажимать клавиши не глядя на них, в том числе, и особенно, клавиши управления курсором. На старом макбуке пальцы легко вслепую находили клавиши управления курсором. Удобнее всего, конечно же, обычная полноразмерная настольная клавиатура, но речь сейчас не о ней.
Следующий момент, вызвавший во мне отторжение и недоумение — это невозможность видеть процесс зарядки аккумулятора в виду полного отсутствия индикаторов как на корпусе ноутбука, так и на зарядном устройстве или кабеле. На старом макбуке с его чудесным MagSafe прямо на разъёме был индикатор. Теперь же, получается, я могу проверить зарядился ли ноутбук только включив его. Да, у айфона такая же беда, но включить экран смартфона всё же проще, чем включить ноутбук.

Однако, несмотря на большие сомнения в удобстве клавиатуры, я решился на переход на новый макбук только ради нормально экрана. Альтернативный вариант — покупка обычного ноутбука и установка на него Линукса — меня не зацепила, хотя на рабочем компьютере у меня как раз Линукс и стоит.

По габаритам и весу описываемые два ноутбука существенно не отличаются. У обоих ноутбуков одна и та же ёмкость аккумулятора — 54,5 Втч. Предположительно у Air автономность должна быть больше, т.к. экран там существенно проще, зато у нового макбука вроде как более энергоэффективные процессоры. В общем надо проверять, хотя судя по первым часам пользования складывается ощущение, что новый макбук немного быстрее разряжается, но выводы делать пока рано.

Впечатление от экрана даже превзошло ожидания — экран впечатляющий, такое ощущение, что у меня зрение стало лучше, настолько всё чёткое )

Продолжение следует...

Policy-routing на CentOS

Довольно распространённая ситуация — на моёй рабочей станции есть два интерфейса и два айпишника, скажем из подсети А и подсети Б. При обращении клиента с хоста из сети Б к моему айпишнику из подсети А ответ к нему уходит через другой интерфейс с моего айпишника из подсети Б, т.к. он из той же подсети, что и адрес клиента. Мне надо сделать, чтобы эти ответы уходили с того же адреса на который пришли.

Тут нужен policy-routing — маршрутизация на основе определённых правил. Логика получается такая: ответы на запросы из подсети Б к моему адресу из подсети А отправлять с адреса из подсети А (т.е. на шлюз подсети А).

Маркируем соединения из сети Б к нашему адресу из сети А при помощи iptables и таблицу mangle (используется для изменения пакетов):
iptables -t mangle -I INPUT -i eth0 -s 10.1.100.0/24 -d 10.2.96.3 -j CONNMARK --set-mark 1
А на выходе копируем маркировку соединения в маркировку пакетов, насколько я понимаю, это означает, что мы маркируем пакеты промаркированных ранее соединений:
iptables -t mangle -I OUTPUT -s 10.2.96.3 -d 10.1.100.0/24 -j CONNMARK --restore-mark
Вероятно, в этом правиле можно обойтись и без указания адресов источника и адресата, но мне кажется так будет правильнее, более точно чтоли )

В таблицу маршрутизации 111 добавляем маршрут для сети Б, но на шлюз из подсети А:
ip route add to 10.1.100.0/24 via 10.2.96.1 dev eth0 table 111
И, наконец, добавляем правило для перенаправления пакетов с нашей маркировкой в отдельную таблицу маршрутизации:
ip rule add fwmark 1 lookup 111

Для удобства можно назначить название для таблицы в файле /etc/iproute2/rt_tables, которое можно будет использовать вместо номера.

Так же нужно проверить не включена ли проверка обратного пути (reverse path checking):
sysctl net.ipv4.conf.eth0.rp_filter
Если включена, то система будет проверять пакеты на соответствие источника интерфейсу, с которого пакет получен. Например, если пакет пришёл с адреса, который виден через другой интерфейс (а не тот, с которого пакет пришёл), то значит этот пакет надо отбросить.

Если всё заработало как надо, то сохраняем правила iptables в файл "/etc/sysconfig/iptables", а правила для маршрутизации в файл "/etc/sysconfig/network-scripts/route-eth0".

Далее несколько вспомогательных команд, которые могут пригодиться.

Посмотреть определённую таблицу маршрутизации:
ip route show table 111
Удалить маршрут из указанной таблицы
ip route del table 111 to 10.1.100.0/24
Посмотреть правила маршрутизации:
ip rule show
Удалить правило маршрутизации:
ip rule del fwmark 1

Как посмотреть правила iptables писать не буду )

Цена на кабели к смартфонам Samsung и Apple

По сути пост ни о чём, все и так знают, что аксессуары Apple неоправданно дорогие. Просто сам столкнулся и так удивился, что решил поделиться )

Понадобились мне кабели USB Type-C и Lightning. За первым я пошёл в фирменный салон Samsung, а за вторым в магазин авторизованного представителя Apple, по крайней мере оба магазина так о себе заявляют.

Кабель Samsung USB Type-C стоит 400 сом, кабель Apple Lightning стоит 1490 сом. Разница более чем в 3,5 раза.
Конечно, кабель USB Type-C в довольно простом пакетике, а кабель Lightning в красивой, добротной коробочке и парой маленьких брошюрок, но они мне не нужны. Какой-то явной разницы в качестве не заметил. Более того, кабель Samsung USB Type-C длиннее примерно на 10 см.

Фирменный кабель Lightning — это не блажь. Предыдущий кабель фирмы Remax (вроде не совсем уж нонейм) визуально более красивый и добротный, в довольно крепкой оплётке, начал глючить — периодически отказывается заряжать айфон, т.е. подключаешь зарядку, а телефон её не видит. Хотя я был с ним очень аккуратен, на нём нет никаких перегибов, потёртостей и других видимых изъянов. Вот я и решил купить фирменный кабель.

Кстати, считаю конструкцию кабеля Lightning намного более удачной нежели кабеля USB Type-C. Разъём со стороны телефона у Lightning явно более крепкий и продуманный — толстая площадка с контактами, которая вставляется в простой разъём телефона, ничего лишнего грубо говоря — палочку вставляешь в дырочку. А кабель USB Type-C, такое ощущение, что специально назло Apple сделали наоборот — вывернули и поэтому получилось сложнее: разъём на кабеле должен надеваться на контактную площадку в разъёме телефона, т.е. должна точно совпасть не только контактная площадка, но и рамка вокруг неё. Разъём Lightning на телефоне сломать надо очень постараться, там нет выступающих частей, а разъём USB Type-C на телефоне — это тонкая контактная площадка внутри углубления. Примерно тоже самое с разъёмами на кабелях — на Lightning, как я уже говорил, толстая контактная площадка и всё, испортить сложно, а на кабеле USB Type-C полость, в которой тонкие контакты. В результате подключение кабеля USB Type-C всё равно требует внимания и аккуратности, хоть теперь и не нужно определять верх-низ разъёма. Тогда как кабель Lightning подключить намного проще, но с другой стороны отключить его немного сложнее — он крепко держится, а ухватиться сложно, т.к. корпус разъёма слишком маленький и гладкий, но это уже придирки )

Cisco Radiusd: NAS-Identifier

В логах Radius-а:
[acct_unique] WARNING: Attribute NAS-Identifier was not found in request, unique ID MAY be inconsistent                     


Смотрим дебуг и, действительно, Radius никакого NAS-Identifier не получает.

Включаем на Cisco:
radius-server attribute 32 include-in-access-req
radius-server attribute 32 include-in-accounting-req


Теперь получаем:
NAS-Identifier = «myhost.domain.tld»

ЛУЧШАЯ КОМАНДА ТЕЛЕМАРКЕТИНГА, ИСХОДЯЩИХ КОНТАКТОВ."Хрустальная Гарнитура"


Делимся. Постим. Лайкаем. Комментируем. Верим. Надеемся. Мечтаем. Желаем и требуем приз!!!

Трансляция VLAN-ов на D-Link

Иногда бывает необходимо поменять номер влана на другой. Например, принимаем от клиента транк с порта 2 и транслируем клиентский влан 1600 во влан 600, который дальше уходит с порта 23:
create vlan 600 tag 600
config vlan vlanid 600 add tag 2,23
config qinq ports 23 role nni outer_tpid 0x8100 # по-умолчанию так и должно быть
enable qinq
config qinq ports 2 role uni
create vlan_translation ports 2 replace cvid 1600 svid 600

Если нужно, чтобы через тот же линк проходили также и другие вланы, то нужно прописать их трансляцию самих в себя:
create vlan 601 tag 601
config vlan 601 tag 2,23
create vlan_translation ports 2 replace cvid 601 svid 601

Таким образом получается, что на порту 2 подключен транк клиента, в котором он передаёт два влана — 1600 и 601, и надо передать их в порт 23. Так получилось, что мы не можем передать в порт 23 влан 1600, поэтому мы перенумеровываем его в 600 и передаём дальше.

Подключение репозитория HP с системными утилитами

Management Component Pack

hp-health HPE System Health Application and Command line Utilities
hponcfg HPE RILOE II/iLO online configuration utility
hp-ams HPE Agentless Management Service
hp-snmp-agents Insight Management SNMP Agents for HPE ProLiant Systems
hpsmh HPE System Management Homepage
hp-smh-templates HPE System Management Homepage Templates
hpssacli HPE Command Line Smart Storage Administration Utility
hpssaducli HPE Command Line Smart Storage Administration Diagnostics
hpssa HPE Array Smart Storage Administration Service

Создаём файл с описанием репозитория /etc/yum.repos.d/mcp.repo:
[mcp]
name=Management Component Pack
baseurl=http://downloads.linux.hpe.com/repo/mcp/dist/dist_ver/arch/project_ver
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/GPG-KEY-mcp

Где:
dist          centos, feodra, opensuse, oracle, asianux
   dist_ver      Browse repo to identify supported distribution versions
   arch          i386, x86_64,  amd64(debian/ubuntu)
   project_ver   current, 10.50, 10.40, 10.20, 10.00, 9.30, 9.25, 9.10 (Browse repo to identify supported project versions)

В моём случае (CentOS 6.8) получился вот такой файл:
[mcp]
name=Management Component Pack
baseurl=http://downloads.linux.hpe.com/repo/mcp/centos/6.8/x86_64/current
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/GPG-KEY-mcp


Посмотреть список пакетов из этого репозитория:
# yum --disablerepo="*" --enablerepo="mcp" list available


Установить пакет:
# yum install packagename
Например:
# yum install hp-health

Cisco: DHCP для выдачи DNS-сервера IPv6-клиентам

Есть PPPoE-клиенты, которые получают IPv6-адреса через SLAAC, префикс сети передаётся Radius-сом, также из Radius-а передаётся маршрут на дополнительную подсеть. Но вот адрес DNS-сервера выдать клиенту можно пока только через DHCP. Команда «ipv6 nd ra-dns-server» не работает, avpair «ipv6-dns-servers-addr» тоже.

Впрочем настройка DHCP-сервера для этих задач совсем несложная, заодно передадим и домен по-умолчанию:
!
ipv6 dhcp server IPV6_DHCP
dns-server 2001:db8:1::1
domain-name elcat.kg
!
interface Virtual-Template1
ipv6 nd other-config-flag
ipv6 dhcp server IPV6_DHCP
!

Опция «ipv6 nd other-config-flag» указывает, кто хостам надо использовать DHCP для других настроек, кроме получения адреса:
Hosts should use DHCP for non-address config

CentOS: данные по сетевой карте

# ip -s -s link show eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether e0:07:1b:f8:21:64 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    1762937170427 11152407427 0       9422    0       3579554
    RX errors: length   crc     frame   fifo    missed
               0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    24857233171258 18559176680 0       0       0       0
    TX errors: aborted  fifo   window heartbeat
               0        0       0       0


# ethtool -g eno1
Ring parameters for eno1:
Pre-set maximums:
RX:             2047
RX Mini:        0
RX Jumbo:       0
TX:             511
Current hardware settings:
RX:             200
RX Mini:        0
RX Jumbo:       0
TX:             511


Поменять текущий параметр (до перезагрузки):
# ethtool -G eno1 rx 1024

Прописать параметр насовсем можно в /etc/sysconfig/network-scripts/ifcfg-eno1:
ETHTOOL_OPTS="-G eno1 rx 1024"