Чуть больше года назад купил Macbook Air 13 2015, RAM 8GB, SSD 256GB.
Всё мне в этом макбуке нравилось кроме экрана и дело не только в разрешении, но и в углах обзора — стоило хоть немного отклониться от идеального угла, как цвет изображения искажался. Это очень раздражало, постоянно приходилось поправлять угол наклона дисплея. А ещё сильно раздражала очень низкая скорость обновления пикселей или время отклика, особенно это бросалось в глаза при прокрутке страниц — всё расплывалось, точнее размазывалось с заметным шлейфом.
Ждал выхода нового макбука и дождался такого, что без ругательств сложно описать, ну вы сами знаете. Решил купить Macbook Pro 13 2015, но найти его в продаже сложно, тем более у нас. Вероятно мне надо было реагировать быстрее, может быть и успел бы. Сейчас же старую модель можно купить разве что без русских букв, да и не особо она и подешевела — 86 тысяч рублей против 95 тысяч за младший новый Macbook Pro. Короче говоря, мучился я, мучился и решил, что придётся попробовать новый Macbook. Остановился на самой доступной версии — Macbook Pro 13 2017 RAM 8GB, SSD 128GB. Купил его 6 февраля 2018 г.
Читать дальше →
Довольно распространённая ситуация — на моёй рабочей станции есть два интерфейса и два айпишника, скажем из подсети А и подсети Б. При обращении клиента с хоста из сети Б к моему айпишнику из подсети А ответ к нему уходит через другой интерфейс с моего айпишника из подсети Б, т.к. он из той же подсети, что и адрес клиента. Мне надо сделать, чтобы эти ответы уходили с того же адреса на который пришли.
Тут нужен 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 писать не буду )
По сути пост ни о чём, все и так знают, что аксессуары 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 подключить намного проще, но с другой стороны отключить его немного сложнее — он крепко держится, а ухватиться сложно, т.к. корпус разъёма слишком маленький и гладкий, но это уже придирки )
В логах 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»
тест
Иногда бывает необходимо поменять номер влана на другой. Например, принимаем от клиента транк с порта 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 и передаём дальше.
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
Есть 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
# 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"
Как настраивать IPv6 на циске писать не буду, да и вообще обойдусь минимумов слов )
Роутер R1
!
interface Vlan111
description R1
ipv6 address FE80::12 link-local
ipv6 address 2001:0db8:1::219/64
ipv6 ospf mtu-ignore
ipv6 ospf 1 area 0
!
router ospfv3 1
router-id 1.1.1.219
passive-interface default
no passive-interface Vlan111
!
address-family ipv6 unicast
area 0 range 2001:0db8::/32
default-information originate
redistribute connected
redistribute static
exit-address-family
!
Роутер R2
!
interface Vlan111
description R2
ipv6 address 2001:0db8:1::247/64
ipv6 ospf 1 area 0
ipv6 ospf mtu-ignore
!
router ospfv3 1
router-id 1.1.1.247
!
address-family ipv6 unicast
passive-interface default
no passive-interface Vlan222
redistribute connected
redistribute static
area 0 range 2001:0db8::/32
exit-address-family
!
Без команды «ipv6 ospf mtu-ignore», заданной на интерфейсах соседи постоянно падают с жалобой «Neighbor Down: Too many retransmissions» и никакие маршруты не передаются.
Команда «default-information originate» на роутере R1 даёт указание роутеру отправлять соседям ещё и default-route.
Несколько команд, чтобы посмотреть интересную информацию:
sh ipv6 route ospf
sh ipv6 ospf database