Изменение кодировки MySQL-базы с latin1 на cp1251

Описание проблемы Допустим, у Вас есть база данных MySQL с кодировкой latin1. В ней не работает сортировка, русский текст не видно в phpMyAdmin и так далее. Вы хотите перевести её в правильную кодировку — cp1251, в которой фактически и находятся данные в базе. Однако простого способа это сделать нет. Решение Делаем полный бэкап базы. С помощью скрипта fixmyenc, текст которого приводится ниже, выполняем следующее: 1 perl fixmyenc HOST DATABASE USER PASSWORD >fixdb.sql Если не происходит никаких ошибок, создаётся файл fixdb.sql — скрипт на языке sql, которым мы и будем чинить базу. (необязательно) Просматриваем созданный файл. Выполняем содержащиеся в нём SQL-запросы: 1 mysql --host=HOST --database=DATABASE --user=USER --password=PASSWORD <fixdb.sql Если и на этом этапе нет никаких ошибок — значит наша база успешно перекодирована. Если ошибки были — восстанавливаем базу из бэкапа, созданного перед началом работы, и сообщаем об ошибке (с её полным текстом) например на страницу обсуждения. Важно: Скрипт fixmyenc написан так, что при малейшей проблеме останавливает свою работу с ошибкой и не создаёт sql-скрипта. Это сделано специально (и не составляет проблемы, поскольку в самой базе при этом ничего не меняется), однако о каждой такой проблеме тоже очень желательно сообщить. После сообщения об ошибке скрипт будет исправлен и новый текст выложен здесь же. Принцип работы Все полнотекстовые индексы (FULLTEXT KEY) удаляются и в конце пересоздаются. CHARACTER SET и COLLATION самой базы, всех таблиц и всех текстовых полей в таблицах меняются сначала с latin1 на binary, а затем с binary на cp1251_general_ci (если бы мы попытались изменить кодировку напрямую из latin1 в cp1251, то MySQL не нашёл бы символов, соответствующих верхней части latin1, в cp1251, и просто заменил бы их знаками вопроса, в результате чего все русские буквы были бы безвозвратно потеряны). Текст скрипта fixmyenc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 #!/usr/bin/perl use warnings; use strict; use DBI; unless( 4 == @ARGV ) { print STDERR "Usage: $0 <host> <database> <user> <password>\n"; exit 1; } my ($host, $database, $user, $password) = @ARGV; die "bad host/db/user" unless $host =~ /^[\w\-\.]+$/ and $database =~ /^[\w_]+$/ and $user =~ /^[\w_]+$/; my $dbh = DBI->connect("DBI:mysql:database=$database;host=$host", $user, $password, {'RaiseError' => 1}); my (@pass0, @pass1, @pass2, @pass3) = (); my $sth = $dbh->prepare("SHOW CREATE DATABASE $database"); $sth->execute; my @arr = $sth->fetchrow_array; $arr[1] =~ /^CREATE DATABASE `$database` \/\*!\d+ DEFAULT CHARACTER SET latin1( COLLATE latin1_\w+)? \*\/$/ or die "bad database spec: $arr[1]"; push @pass1, "ALTER DATABASE `$database` DEFAULT CHARACTER SET binary"; push @pass2, "ALTER DATABASE `$database` DEFAULT CHARACTER SET cp1251 COLLATE cp1251_general_ci"; $sth = $dbh->prepare("SHOW TABLES"); $sth->execute; my @tables = (); while( my @row = $sth->fetchrow_array ) { die "bad table name: $row[0]" unless $row[0] =~ /^[\w_]+$/; push @tables, $row[0]; } foreach my $table (@tables) { $sth = $dbh->prepare("SHOW CREATE TABLE `$table`"); $sth->execute; my @row = $sth->fetchrow_array; $row[1] =~ s/ COMMENT='[^'\\]*'$//s; $row[1] =~ /^CREATE TABLE `$table` \(.*\)([^)]+)$/s or die "bad table spec: $row[1]"; my $tail = $1; unless( $tail =~ /\bDEFAULT CHARSET=latin1\b/ ) { die "bad table $table spec tail: $tail"; } push @pass1, "ALTER TABLE `$table` DEFAULT CHARSET binary"; push @pass2, "ALTER TABLE `$table` DEFAULT CHARSET cp1251 COLLATE cp1251_general_ci"; my (%fulltext, %column_in_fulltext_indexes, %remove_fulltext_indexes) = (); $sth = $dbh->prepare("SHOW INDEX FROM `$table`"); $sth->execute; while( my $row = $sth->fetchrow_hashref ) { next unless $row->{Index_type} eq "FULLTEXT"; $fulltext{$row->{Key_name}} ||= []; $fulltext{$row->{Key_name}}[$row->{Seq_in_index}-1] = $row->{Column_name}; $column_in_fulltext_indexes{$row->{Column_name}} ||= []; push @{$column_in_fulltext_indexes{$row->{Column_name}}}, $row->{Key_name}; } $sth = $dbh->prepare("SHOW FULL COLUMNS FROM `$table`"); $sth->execute; while( my @row = $sth->fetchrow_array ) { my ($column, $type, $collation) = @row[0,1,2]; if( defined $collation and "NULL" ne $collation ) { die "bad collation in column $column of table $table: $collation" unless $collation =~ /^latin1_\w+$/; push @pass1, "ALTER TABLE `$table` MODIFY COLUMN `$column` $type CHARACTER SET binary"; push @pass2, "ALTER TABLE `$table` MODIFY COLUMN `$column` $type CHARACTER SET cp1251 COLLATE cp1251_general_ci"; foreach my $index (@{$column_in_fulltext_indexes{$column}}) { $remove_fulltext_indexes{$index} = 1; } } } foreach my $index (keys %remove_fulltext_indexes) { push @pass0, "ALTER TABLE `$table` DROP INDEX `$index`"; push @pass3, "ALTER TABLE `$table` ADD FULLTEXT INDEX `$index` (" . join( ",", map { "`$_`" } @{$fulltext{$index}} ) . ")"; } } print join ";\n", "USE `$database`", @pass0, @pass1, @pass2, @pass3, ""; Источник 1gb.ru

6 лютого 2022 · 4 хвилин · 732 слів · dimetrius

Подготовка образов для KVM/LibVirt

В качестве примера будет использован образ Ubuntu 16.04: подготовка рабочего окружения, настройка необходимых параметров, сборка и загрузка образа в облачный сервис. Также будут рассмотрены необходимые шаги для подготовки образа с полной совместимостью со всеми дополнительными возможностями сервиса «Виртуальное приватное облако». В качестве инструмента для сборки образа мы будем использовать diskimage-builder. Это набор компонентов для подготовки образов операционных систем, файловых систем, RAM-дисков с открытым исходным кодом, поддерживаемый сообществом OpenStack. Инструмент поддерживает создание образов большинства распространенных дистрибутивов GNU/Linux: Centos Debian Fedora RHEL Ubuntu Gentoo OpenSUSE По умолчанию diskimage-builder подготавливает образ cloud-версии операционной системы, поэтому в образе будут присутствовать пакеты cloud-init и cloud-utils, необходимые для автоматической настройки системы в облаке. Создание образа Ubuntu 16.04 Мы будем готовить образ на машине с ОС Ubuntu 14.04. Для начала установим необходимые зависимости: 1 2 sudo apt update sudo apt -y install python-pip curl Затем установим diskimage-builder: 1 sudo pip install diskimage-builder Создадим базовые директории для работы: 1 mkdir -p ~/diskimage-builder/{images,elements} Для настройки diskimage-builder нам необходимо указать несколько дополнительных параметров, значение которых хранится непосредственно в переменных окружения командной оболочки (таким образом, вы можете указывать их в командной строке): ARCH=“amd64” — архитектура образа. BASE_ELEMENTS=“ubuntu bootloader cloud-init-datasources” — здесь мы укажем используемые элементы diskimage-builder. Элементы представляют собой набор bash-скриптов, которые выполняют все рутинные действия по подготовке и изменению образа. Наиболее важным для нас является элемент ubuntu, который скачает и распакует стандартный официальный образ дистрибутива, проведет установку требуемых пакетов и обновления системы до актуального состояния внутри образа при помощи утилиты chroot, и соберет все обратно в образ, готовый к использованию. Элемент bootloader устанавливает загрузчик (в нашем случае GRUB2) в подготавливаемый образ системы, а cloud-init-datasources передаёт список источников данных для утилиты cloud-init, которая необходима для первоначальной настройки операционной системы при запуске. DIB_CLOUD_INIT_DATASOURCES=“ConfigDrive, Ec2” — источники данных для элемента cloud-init-datasources. DIB_RELEASE=“xenial” — версия операционной системы, на базе которой мы будем создавать образ. IMAGE_PATH="~/diskimage-builder/images/ubuntu-16.04" — имя и путь для образа. Сборка образа осуществляется с помощью команды: ...

5 листопада 2021 · 10 хвилин · 2092 слів · dimetrius

IMAPS gateway with getmail and dovecot

It had been a while I wanted to have another solution for hosting and serving emails than Gmail. Especially because I am currently working on the Linux Kernel and at some point I would like to submit a few patches. Unfortunately, it is impossible to use Gmail for sending patches or even, to a greater extend, to be involved in the LKML. Also I think it is pretty fancy (nerdy?) to have my own email address, i.e. [email protected]. At the same time, I have always heard that managing a full email stack (from the mx DNS records up to the IMAP and SMTP servers) is a pain. It can definitely happen that my server is down for a few days which would mean that my emails would be inaccessible in the meantime. That is why I had this idea of using a stable frontend (i.e. via OVH, my hosting service company) before my own email server, so that whenever my server is down, I can still access my emails through this frontend. One could argue that I could just use the email facility that OVH provides but there are (at least) two reasons I prefer not to: The mailbox OVH offers me is only 2G in size, which is fairly small nowadays. I would like to manage my own data (I like the cloud, but only if it is mine!) Here is a picture of what I wanted to achieve (thanks to Asciiflow for the following ASCII Flow Diagram): ...

12 грудня 2019 · 9 хвилин · 1773 слів · dimetrius

Ограничение скорости обработки запросов в nginx

NGINX великолепен! Вот только его документация по ограничению скорости обработки запросов показалась мне, как бы это сказать, несколько ограниченной. Поэтому я решил написать это руководство по ограничению скорости обработки запросов (rate-liming) и шейпингу трафика (traffic shaping) в NGINX. Мы собираемся: описать директивы NGINX, разобраться с accept/reject-логикой NGINX, визуализировать обработку всплесков трафика на различных настройках. Директивы NGINX по ограничению скорости обработки запросов В этой статье мы будем говорить о ngx_http_limit_req_module, в котором реализованы директивы limit_req_zone, limit_req, limit_req_status и limit_req_level. Они позволяют управлять значением кода состояния HTTP-запроса для отклоненных (rejected) запросов, а также логированием этих отказов. Чаще всего путаются именно в логике отклонения запроса. Сначала нужно разобраться с директивой limit_req, которой требуется параметр zone. У него также есть необязательные параметры burst и nodelay. Здесь используются следующие концепции: zone определяет «ведро» (bucket) — разделяемое пространство, в котором считаются входящие запросы. Все запросы, попавшие в одно «ведро», будут посчитаны и обработаны в его разрезе. Этим достигается возможность установки ограничений на основе URL, IP-адресов и т. д. burst — необязательный параметр. Будучи установленным, он определяет количество запросов, которое может быть обработано сверх установленного базового ограничения скорости. Важно понимать, что burst — это абсолютная величина количества запросов, а не скорость. nodelay — также необязательный параметр, который используется совместно с burst. Ниже мы разберемся, зачем он нужен. Каким образом NGINX принимает решение о принятии или отклонении запроса? При настройке зоны задается ее скорость. Например, при 300r/m будет принято 300 запросов в минуту, а при 5r/s — 5 запросов в секунду. ...

7 червня 2019 · 7 хвилин · 1337 слів · dimetrius

Диагностика работы DNS

Зачастую, в силу того, что информация в сети распространяется не мгновенно, привязанные к серверу домены начинают работать не сразу. Чтобы не тратить время впустую, ожидая обновления кеша DNS, желательно сразу проверить настройку вашего DNS-сервера и убедиться, что по истечении 72 часов (это максимальное время обновления глобального кеша DNS) ваш домен заработает. Первичная диагностика Whois Начать диагностику следует с запроса whois: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [root@dns ~]# whois firstvds.ru % By submitting a query to RIPN's Whois Service % you agree to abide by the following terms of use: % http://www.ripn.net/about/servpol.html#3.2 (in Russian) % http://www.ripn.net/about/en/servpol.html#3.2 (in English). domain: FIRSTVDS.RU nserver: ns1.firstvds.ru. 82.146.43.2 nserver: ns2.firstvds.ru. 94.250.248.160 state: REGISTERED, DELEGATED, VERIFIED org: CJSC "Pervyj" registrar: REGTIME-REG-RIPN admin-contact: http://whois.webnames.ru created: 2002.08.07 paid-till: 2014.08.08 free-date: 2014.09.08 source: TCI Last updated on 2014.03.18 03:36:35 MSK В данном примере мы видим, что домен проделегирован на сервера имен ns1.firstvds.ru. и ns2.firstvds.ru. с указанием IP-адресов (дочерние NS-сервера всегда прописываются с указанием IP). Это корректный вывод whois и примерно так должен выглядеть ответ whois для зарегистрированного и проделегированного домена. Исключение составляет IP, он указывается только для дочерних NS-серверов. ...

21 лютого 2018 · 13 хвилин · 2749 слів · dimetrius

Как работает DNS

Определение DNS (Domain Name System, «система доменных имён») — компьютерная распределённая система для получения информации о доменах. Основная область применения данной системы — преобразование имени хоста в IP-адрес и предоставления данных о маршрутизации почты. Хост — это любой компьютер или сервер, подключенный к локальной сети или интернету. Принцип работы Схематичное представление процесса определения определения IP-адреса по вводимому имени домена Работа DNS достаточно проста, но из-за незнания её основ возникает основная масса проблем и вопросов при переносе существующего доменного имени и регистрации нового. Остановимся немного подробней на описании самой схемы. Когда пользователь запускает веб-браузер и вводит название домена сайта, его ПК отправляет запрос к DNS-серверу интернет-провайдера для получения IP-адреса, на котором находится домен (1). Если DNS-серверы провайдера не обнаруживают в своем кэше информации о запрашиваемом сайте, то отправляют запрос на корневые DNS-серверы (2). Корневой DNS-сервер ищет в своей базе данных информацию о серверах имен хостинг-провайдера, на которых присутствует этот сайт. Далее, он сообщает их кэширующему DNS-серверу провайдера (3). После того, как кэширующий DNS-сервер интернет-провайдера получает информацию о серверах имен хостинг-провайдера он опрашивает любой из них (4) и, в случае получения положительного результата получения IP-адреса (5), помещает в кэш. Кэширование используется для того, чтобы снизить как нагрузку на интернет-каналы, так и для ускорения получения результата запроса. После этого DNS-сервер провайдера передает IP-адрес браузеру пользователя, совершившему запрос сайта (6). И уже после этого браузер, получив IP-адрес запрашиваемого сайта, переходит на сам сайт (7 и 8). Или вот более точное описание процесса. Ваш браузер об IP-адресе test.ru ничего не знает и с запросом IP-адреса через специальную программу — resolver обращается к локальному серверу имен. Локальный DNS-сервер — это сервер имен вашей локальной сети или DNS-сервер вашего интернет-провайдера. «Откуда браузеру известно о существовании этого локального DNS?» — спросите вы. Все предельно просто. При настройках сетевого подключения вы прописываете IP-адреса DNS-серверов (предпочитаемого и/или альтернативного), один из которых будет отвечать на запросы, посылаемые вашим браузером через resolver — это и есть локальный или местный сервер вашей сети. Вы всегда можете посмотреть IP-адрес вашего локального DNS-сервера. Для этого достаточно посмотреть свойства сетевого подключения, используемого на вашем компьютере. Запрос на IP-адрес test.ru доходит до местного сервера имен. Этот сервер о данном IP-адресе ничего не знает и посылает запрос одному из корневых серверов «.» (root). Корневой сервер отдает локальному серверу IP-адрес сервера, который поддерживает зону .RU. Далее по полученному адресу локальный сервер имен обращается к DNS-серверу, который поддерживает .RU. Этот DNS-сервер, в свою очередь, по полученному запросу отдает IP-адрес сервера, который поддерживает зону test.ru. Местный DNS-сервер с запросом IP-адреса test.ru обращается к DNS-серверу зоны test.ru. Локальный сервер имен получает IP-адрес test.ru от DNS-сервера зоны test.ru. Получив адрес test.ru, локальный DNS-сервер сообщает его вашему браузеру. Важно, что обновление информации о сервера имен провайдера происходит не мгновенно, а через некоторое определенное (для каждого DNS-сервера, в зависимости от настроек и провайдера данные значения могут варьироваться) время. ...

21 лютого 2018 · 3 хвилин · 589 слів · dimetrius

Использование истории команд в BASH на LINUX

Вступление В серверной среде работа с командной строкой занимает много времени. Часто используется оболочка bash – командная оболочка по умолчанию большинства дистрибутивов. Вероятно, во время терминальной сессии общие команды будут повторяться часто, а вариации данных команд – еще чаще. Конечно, сначала набирать каждую команду вручную очень полезно, так как это – лишняя возможность попрактиковаться, но в какой-то момент это начинает надоедать и раздражать. К счастью, bash-оболочка имеет некоторые довольно хорошо разработанные функции истории. Умение продуктивно использовать и управлять историей в bash позволяет тратить меньше времени на ввод команд, и тем самым увеличивает объем выполненной работы. Как известно, среди разработчиков популярен так называемый принцип DRY (Don’t Repeat Yourself). Продуктивное использование истории в bash помогает работать с информацией согласно данному принципу. Это руководство демонстрирует все функции на Linux Ubuntu 12.04, но почти все современные дистрибутивы Linux будут работать подобным образом. Настройки истории в bash Прежде чем использовать историю, нужно отредактировать некоторые настройки bash, чтобы сделать ее более применимой. Bash позволяет редактировать количество предыдущих команд, которые нужно сохранить в истории. Для этого в bash есть две отдельные опции: параметр «HISTFILESIZE» задает количество команд, хранящихся в файле истории, а «HISTSIZE» указывает количество команд, которое сохраняется в памяти для текущей сессии. Это означает, что в памяти можно установить разумные пределы размера истории для текущего сеанса, а также хранить более объемную историю на диске для дальнейшего использования. ...

8 жовтня 2017 · 12 хвилин · 2365 слів · dimetrius

OpenSSL, ssl_ciphers и nginx: прокачиваем на 100%

Много где написано о том, как получить 100% и A+ по тесту от Qualys. При всём при том практически везде директивы ssl_ciphers и подобные даются как эдакие магические строки, которые нужно просто вставить, и надеяться, что автор не подводит вас под монастырь. Эта статья призвана исправить это недоразумение. По прочтению этой статьи директива ssl_ciphers потеряет для вас всякую магию, а ECDHE и AES будут как друзья да братья. Подготовка Работать будем с Debian 8.7. Если у вас другой дистрибутив, то версии должны быть такие же или более новые. 1 2 3 4 5 6 7 8 # lsb_release -d Description: Debian GNU/Linux 8.7 (jessie) # openssl version OpenSSL 1.0.1t 3 May 2016 # nginx -V nginx version: nginx/1.6.2 Настроим nginx для получения сертификатов от Let’s Encrypt по инструкции, но только до получения сертификата для нашего домена. 1 certbot certonly -d example.com -d www.example.com Конфиг используем минимальный. Ничего лишнего. Всё по умолчанию. 1 2 3 4 5 6 7 8 server { server_name www.example.com example.com; listen 443 ssl default_server; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; } Теперь прогоним тест для этого сервера. ...

4 квітня 2017 · 11 хвилин · 2334 слів · dimetrius

Дизайн шаблона Joomla CMS

Слово Jumla на языке суахили означает «все вместе», «как одно целое». Когда-то давно, довольно долгое время я верстал сайты на HTML/CSS/JavsScript и не имел никакого представления о CMS. Пугающим моментом было то, что как я полагал владение PHP является крайне необходимым, однако по факту каких-то базовых знаний оказалось достаточно (простой код оказывается понятен программисту любого другого языка, а в дебри лезть не обязательно). Для человека, владеющего только версткой и скриптами, довольно достаточно знать какие-то определенные моменты, для того, чтобы с ходу приступить к работе с Joomla. Что-то в этих моментах схоже с другими CMS, что-то отличается. Постарался изложить эти моменты кратко. Если бы они мне были известны сразу, то смог бы начать создавать администрируемые пользователями сайты гораздо быстрее. Итак, если вы владеете HTML, но не имеете представления о CMS Joomla, то вам следует нажать кнопку ниже. Для общего представления основные понятия этой CMS: Шаблон/Template – совокупность папок/файлов, определяющих компоновку и дизайн страниц сайта. На одном сайта можно иметь множество установленных шаблонов. Таким образом можно изменять дизайн сайта за считанные секунды, переключив с одного шаблона на другой. В HTML шаблоне определены области страницы (как правило, это div блоки), в которых будет выводится определенное содержимое. Например, как правило, в центральной области отображается содержимое страницы. Владелец/автор сайта будет иметь возможность создавать статьи-артикулы с помощью встроенного редактора WYSIWYG, которые и будут отображаться в этой области. Также в HTML шаблоне могут быть определены области для отображения различных объектов. Как правило, это такие области как: шапка документа (то, что всегда отображается вверху), подвал (то что отображается внизу), область для меню, какие-то области по бокам. Здесь уже все зависит от пожеланий автора шаблона. Эти области называют позициями. У шаблона есть и другие функции, которые будут описаны далее. Модуль/Module – объект с HTML/PHP/CSS/JavaScript кодом, который может быть отображен в определенных отведенных для этого местах страницы. Пример типичных моделей: переключатель языка сайта, блок авторизации на сайте, строка с поиском по сайту, голосование и т.п. Плагин/Plugin– это объект с HTML/PHP/CSS/JavaScript кодом, который может быть встроен внутрь содержимого страницы. Отличие от модуля только в месте отображения на странице. Автор артикула, при работе в WYSIWYG редактором будет иметь возможность вставить определенный код (подобный HTML коду). На самом сайте этот код будет заменен на объект подобный модулю. Компонент/Component – глобальный объект, который имеет множество настроек. Как правило, в придачу к компоненту идут и модули и плагины. Для примера компонентом может быть гостевая книга, интернет-магазин, форум. Все эти объекты имеют множество настроек и могут выводится отдельной страницей. WYSIWYG редактор – текстовый онлайн редактор (what you see is what you get). С помощью упрощенной панели, похожей на панель Microsoft Word или WordPad можно создавать статьи, которые редактор автоматически преобразует в код HTML. ...

13 квітня 2016 · 10 хвилин · 2056 слів · dimetrius

Настройка Ubuntu сетевым шлюзом для раздачи интернета в локальную сеть

В этой заметке будет рассказано как с помощью iptables настроить системы с Ubuntu 9.10-11.04, Debian 5 и 6 для раздачи интернета другим компьютерам локальной сети. На простом примере будет показано как машину с двумя сетевыми интерфейсами (в один поступает интернет, из другого — «выходит») сделать шлюзом. Допустим, что аппаратно-сетевая часть уже полностью настроена, на вашей машине имеются работоспособный интернет и вы видите другие компьютеры сети. Поэтому давайте разберемся что к чему, для этого введем команду: 1 ifconfig Она выдаст список работающих в данный момент сетевых интерфейсов. Среди них надо опознать те, что начинаются со слов «Link encap:Ethernet» — это интерфейсы сетевых карт. Как правило, это eth0 и eth1. Теперь потребуется опознать в какой из них поступает интернет, а из какого «выходит». Проще всего это сделать по их ip-адресам. Итак, допустим через eth0 вы получаете интернет (например через adsl-модем по протоколу ppp), а eth1 связывает вас с локальной сетью. Если локальная сеть настроена через Network Manager, то мы рекомендуем прописать эти настройки непосредственно в системном конфигурационном файле сети: 1 sudo nano /etc/network/interfaces Здесь исправьте настройки вашего сетевого интерфейса, подключенного к локальной сети (в нашем случае eth1), соответствующим образом: 1 2 3 4 5 6 auto eth1 iface eth1 inet static address 192.168.0.10 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 Значение address — это айпи вашей машины в локальной сети, по этому адресу собственно и будет располагаться шлюз. Значение netmask — в локальных сетях для этого диапазона чаще всего такая. Для других диапазонов можно вычислить здесь. Значения network и broadcast будут зависеть от вашего адреса. То есть, если ваш локальный ip — 10.0.0.10, то network и broadcast будут 10.0.0.0 и 10.255.255.255 соответственно. ...

10 жовтня 2014 · 4 хвилин · 676 слів · dimetrius