Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

21.01.2017

Google
WWW CITForum.ru
С Новым годом!

Статическая IP-маршрутизация

(пособие для начинающего администратора)
Дмитрий Карпов, МИСиС

Сеть Internet с ее протоколами изначально задумывалась как протяженная (WAN - Wide Area Network), состоящая из большого количества машин, соединенных с помощью разных сред обмена данными (как локальных сетей, так и глобальных соединений). Теоретически в Internet могут напрямую работать друг с другом около четырех миллиардов машин (2^32 за вычетом некоторых специальных номеров), а через proxy и того больше.

В силу этих причин Internet - сегментированная сеть. Сегментом является либо прозрачный участок широковещательной (Ethernet) или маркерной (TokenRing) сети, либо соединение точка-точка (модемное).

Теперь - обозначения. IP-номер - четырехбайтное число, записываемое либо в шестнадцатеричном виде типа 0xC0A80E05, либо в десятичном виде, где байты разделены точками типа 192.168.14.5 (в качестве примера в обоих случаях использовался один и тот же номер).

Маска - тоже четырехбайтное число, но все старшие биты, начиная с некоторого, всегда установлены в единицу, а все младшие - в ноль. Примеры: 255.255.255.0 - маска сети класса C на 256 номеров; 255.255.255.192 - маска маленькой сети на 64 номера (192=256-64). Если мне надо указать сочетание номера и маски, я буду использовать запись номер/число_установленных_битов_в_маске - так сочетание номера 192.168.14.5 и маски 255.255.255.0 будет записано в виде 192.168.14.5/24.

Номером сети называют число, получаемое из номера интерфейса применением побитовой операции AND с маской, т.е. в номере интерфейса обнуляются биты на тех местах, на которых стоят нулевые биты в маске.

Следует помнить, что IP-номер присваивается не компьютеру, а интерфейсу (сетевому выходу либо последовательному порту). В принципе можно дать нескольким интерфейсам один номер, но это может вызвать сложности. Можно также присвоить несколько адресов одному интерфейсу.

В сегменте сети все машины имеют IP-номера с одинаковым номером сети и одинаковой маской. В одной локальной сети можно совместить две и больше разных IP-сетей, они даже могут знать друг о друге и нормально общаться, но это все-таки будут две разные сети.

Принято следующее деление в зависимости от значения старшего байта IP-адреса:

  • 0..127 - сети класса A по 2^24 адресов с маской 0xFF000000;
  • 128..191 - сети класса B по 2^16 адресов с маской 0xFFFF0000;
  • 192..223 - сети класса C по 2^8 адресов с маской 0xFFFFFF00;
  • 224..239 - сети класса D для multicast (групповой) рассылки;
остальные пока зарезервированы.

Многие программы по адресу автоматически определяют класс сети, хотя это можно поправить вручную. В принципе никто не мешает разбить сеть на две или больше подсетей с любыми масками, но организациям как правило выделяют адреса блоками, соответствующими классам A, B и C - это связано с системой DNS, позволяющей узнать доменное имя машины по ее IP-адресу.

Сеть класса A с номером 127 - loopback, т.е. предназначена для общения компьютера с собой. В любой сети номер (IP-номер AND маска) является номером всей сети и не может быть присвоен никому конкретно. Номер (IP-номер OR NOT маска), являющийся последним номером в сети, предназначен для broadcasting (широковещательных) сообщений, которые доставляются всем машинам сегмента сети. Соответственно, при выделении группы адресов в сеть два адреса становятся недоступны.

Рассмотрим маршрутизацию в терминах FreeBSD (будет также дан перевод в нотацию System V (Linux, SCO) и Windows3.11). В Unix команды настройки сети, как правило, заюпускаются из файла /etc/rc или запускаемых из него файлах, а в MS Windows - загрузчиком операционной системы в соответствие с system.ini или registry.

Главному шлюзу я всегда присваиваю первый (наименьший) номер в сети (нулевой, как я уже говорил, недоступен). Если в сети присутствует второй шлюз, через который подсоединен другой сегмент, то этому шлюзу (промежуточному маршрутизатору) будет присваиваться последний (наибольший) номер в сети. Для этого нет никаких разумных причин - так мне хочется.


Построим первый сегмент сети:
Сконфигурируем рабочую станцию:

	ifconfig ep0 inet 192.168.1.5 netmask 255.255.255.0

	ifconfig lo0 inet 127.0.0.1 netmask 255.0.0.0

	route add default 192.168.1.1

	
На самом деле в современных (начиная с 2.1.*) версиях FreeBSD это оформляется немного совсем по другому. :-)
Рассмотрим внимательнее, что делают эти команды:

	ifconfig ep0 inet 192.168.1.5 netmask 255.255.255.0

	
присвоила интерфейсу ep0 номер 192.168.1.5, а также создала в таблице маршрутизации запись о том, что все пакеты с номером сети 192.168.1.0/24 будут направляться прямо через этот интерфейс с использованием протокола ARP.

	ifconfig lo0 localhost

	
конфигурирует интерфейс loopback, т.е. "петлю". Этот интерфейс должен иметь адрес 127.0.0.1 и маску 255.0.0.0 на любой машине, имеющей IP, поэтому некоторые системы (например, MS Windows) делают это автоматически, не требуя от администратора (или пользователя, если он сам настраивает систему) задавать параметры loopback. Так как этот интерфейс настраивается на каждой машине одинаково, я не буду писать эту строчку каждый раз. localhost определяется по файлу /etc/hosts, в котором содержится

	127.0.0.1	localhost.домен localhost

	
а маска берется по умолчанию - 255.0.0.0.

	route add default 192.168.1.1

	

замечу, что маршрутизация "default" на самом деле есть "inet 0x0 netmask 0x0" и это надо прописывать, если старая версия команды route не понимает слова "default". создала запись, в соответствии с которой все пакеты (все, потому что любой пакет подходит под 0.0.0.0/0) будут отправляться на машину, имеющую интерфейс 192.168.1.1. Информация о том, как можно добраться до интерфейса 192.168.1.1 содержится в предыдущей команде, которая определила способ доступа ко всем машинам 192.168.1.* через интерфейс ep0.

Таким образом, у нас сложилась примерно такая ситуация:
Вообще система маршрутизации (за исключением предельно примитивных случаев) древовидна, т.е. одни записи включают в себя другие. Частичное пересечение невозможно, ибо границы адресного пространства, на которое действует каждая запись, выровняны на размер этого пространства. Порядок хранения и просмотра таблицы может быть разный, но должен обеспечивать приоритет записей с маленьким пространством перед записями с большим пространством. В данном случае обращение к машине 192.168.1.9 попадает под юрисдикцию обеих записей, но обращаться к ней наша рабочая станция будет в соответствии с 192.168.1.0/24->ep0.

Интерфейс шлюза надо сконфигурировать так:


	ifconfig ed1 inet 192.168.1.1 netmask 255.255.255.0

	
На самом деле у нашего шлюза много интерфейсов и они будут конфигурироваться по мере надобности. Еще раз обращаю внимание на то, что номер и маска сети совпадают для всех машин этого сегмента.

Второй сегмент содержит в себе машину, к которой по последовательной линии с помощью протокола SLIP подсоединен еще один компьютер.
Сконфигурируем ws.2.1:

	slattach -S 0 [...]

	ifconfig sl0 192.168.1.81 192.168.1.82 up

	ifconfig ep0 inet 192.168.2.7 netmask 255.255.255.0

	route add default 192.168.2.1

Сконфигурируем ws.2.2:

	slattach -S 0 [...]

	ifconfig sl0 192.168.1.82 192.168.1.81 up

	route add default 192.168.1.81

Сконфигурируем шлюз:

	ifconfig ed2 inet 192.168.2.1 netmask 255.255.255.0

	route add host 192.168.2.81 192.168.2.7

	route add host 192.168.2.82 192.168.2.7

Третий сегмент будет сочетать в себе две сети - сеть класса C 192.168.2.*/24 и сеть класса B 172.16.*.*/16.
Начнем с шлюза. Ему присвоим два адреса, по одному из каждой сети:

	ifconfig ed3 inet 192.168.3.1 netmask 255.255.255.0

	ifconfig ed3 inet 172.16.0.1 netmask 255.255.0.0 alias...

Теперь ws.3.1 - ей дадим адрес только из первой сети:

	ifconfig ep0 inet 192.168.3.7 netmask 255.255.255.0

	route add default 192.168.3.1

В такой конфигурации ws.3.1 отлично сможет общаться с машинами из сети 192.168.3.0/24 и с машинами вне сегмента локальной сети. При попытке же обратиться к машине того же сегмента, но другой IP-сети, пакет будет послан на шлюз. Шлюз знает, что пакеты с этим адресом надо послать в ту локальную сеть; но некоторые операционные системы работают по алгоритму маршрутизации, в котором запрещено посылать пакет туда, откуда он пришел - это делается для того, чтобы избежать зацикливания пакетов.
Во избежание этого ws.3.2 мы настроим с учетом того, что в локальной сети работают машины с адресами из другой IP-сети:

	ifconfig ep0 inet 172.16.8.14 netmask 255.255.0.0

	route add -net 192.168.3.0 -netmask 255.255.255.0 172.16.8.14

	route add default 172.16.0.1

Здесь мы присвоили интерфейсу номер из сети 172.16.*.*, а затем обьявили, что пакеты для сети 192.168.3.* надо отправлять в ту же локальную сеть.
Маршрутизация по умолчанию могла быть направлена и на адрес 192.168.3.1, но приведенная конструкция проще в том смысле, что обе маршрутизации опираются на интерфейс и не зависят друг от друга. Я не знаю, различаются ли эти варианты по эффективности, а если различаются, то насколько; но чем меньше зависимостей в конфигурации, тем проще ее настраивать и диагностировать при сбоях.
И наконец, любой машине можно присвоить два адреса - по одному из каждой IP-сети. Как правило, это делается в случае, когда часть машин имеет IP-адреса, выделенные провайдером, а остальные работают с Intranet'овскими номерами - их всегда в избытке.

Следующую сеть класса C сегментируем маршрутизатором, который отделит подсеть на 16 IP-номеров (14 машин, включая маршрутизатор).

Шлюз:

	ifconfig ed3 inet 192.168.4.1 netmask 255.255.255.0

	route add -net 192.168.4.128 -netmask 255.255.255.240 192.168.4.254

Рабочая станция ws.4.1:

	ifconfig ep0 inet 192.168.4.7 netmask 255.255.255.0

	route add default 192.168.4.1

Я не указал маршрутизацию


	route add -net 192.168.4.128 -netmask 255.255.255.240 192.168.4.254

Ее можно не указывать и для маршрутизатора. Но! Если какая-нибудь из машин сегмента 192.168.4.128/28, например, 192.168.4.137, обратится к машине из основного (примыкающего к шлюзу) сегмента (в том числе к шлюзу), то протокол ARP зафиксирует приход пакета с сетевой карты, маршрутизатора, выходящей в основной сегмент (IP-номер 192.168.4.127) и далее будет посылать пакеты на эту сетевую карту, и это будет правильно.
Отдельную проблему представляет обращение машины из основного сегмента в 192.168.4.128/28. В отсутствие у ARP сведений об этом номере будет разослан широковещательный запрос и тут все зависит от сообразительности промежуточного маршрутизатора router.4 - если он догадается, что пакет предназначен в подсеть и протранслирует его туда, то ответ приведет к появлению записи в таблицах ARP, не догадается - придется прописывать маршрутизацию.

Маршрутизатор router.4:

	ifconfig ep0 inet 192.168.4.127 netmask 255.255.255.0

	ifconfig ep1 inet 192.168.4.129 netmask 255.255.255.240

	route add default 192.168.4.1

Рабочая станция ws.4.2:

	ifconfig ep0 inet 192.168.4.137 netmask 255.255.255.240

	route add default 192.168.4.129


А эту сеть (тоже класса C) сегментируем маршрутизатором, который разобьет сеть на две равные части.

Шлюз:

	ifconfig ed3 inet 192.168.5.1 netmask 255.255.255.128

	route add -net 192.168.5.128 -netmask 255.255.255.128 192.168.5.127

Рабочая станция ws.5.1:

	ifconfig ep0 inet 192.168.5.7 netmask 255.255.255.128

	route add -net 192.168.5.128 -netmask 255.255.255.128 192.168.5.127

	route add default 192.168.5.1

Маршрутизатор router.5:

	ifconfig ep0 inet 192.168.5.127 netmask 255.255.255.128

	ifconfig ep1 inet 192.168.5.129 netmask 255.255.255.128

	route add default 192.168.5.1

Рабочая станция ws.5.2:

	ifconfig ep0 inet 192.168.5.137 netmask 255.255.255.128

	route add default 192.168.5.129

Разница с предыдущим случаем в том, что сеть разделена на сегменты, содержащие только "куглое" число IP-номеров (два в целой степени). Это особый случай, когда логичнее оформить каждую сеть отдельно.


Теперь сделаем две сети, соединенные через последовательную линию по протоколу PPP.

Шлюз:

	ifconfig ed3 inet 192.168.6.1 netmask 255.255.255.0

	route add -net 172.17.14.192 -netmask 255.255.255.252 192.168.6.127

	route add -net 192.168.6.128 -netmask 255.255.255.240 192.168.6.127

Маршрутизатор rt.6.1:

	ifconfig ep0 inet 192.168.6.127 netmask 255.255.255.128

	pppd 172.17.14.193:172.17.14.194 netmask 255.255.255.252 [...]

	route add -net 192.168.6.128 -netmask 255.255.255.240 172.17.14.194

	route add default 192.168.6.1

pppd требует при запуске указать интерфейс, через который происходит соединение, и его параметры, но это не относится к теме и обозначено [...].
Маршрутизатор rt.6.2:

	ifconfig ep0 inet 192.168.6.129 netmask 255.255.255.240

	pppd 172.17.14.194:172.17.14.193 netmask 255.255.255.252 [...]

	route add default 172.17.14.193

Рабочая станция ws.6.2:

	ifconfig ep0 inet 192.168.6.137 netmask 255.255.255.240

	route add default 192.168.6.129

	
Подсеть на 16 машин выделена аналогично примеру 4. Я надеюсь, разбиение сети на подсети "круглого" размера, соединенные по ppp, после усвоение прочитанного окажется под силу любому.

Как видите, самая простая конфигурация - у машин в сегменте с единственной IP-сетью и с единственным шлюзом (он же шлюз по умолчанию). Чем больше шлюзов в сегменте сети и чем сложнее их конфигурация, тем сложнее корректно настроить рабочие станции, а настраивать надо каждую. Немного выручает протокол DHCP, но:

  1. сервер DHCP должен находиться в том же сегменте локальной сети, что и его клиенты;
  2. сервер DHCP должен корректно конфигурировать клиентов, что опять же непросто в сложной сегментированной сети.
Таким образом, я рекомендую выводить все сегменты на один маршрутизатор (если он справляется с нагрузкой) либо пользоваться возможностями, предоставляемыми динамической маршрутизацией.

Примечания:


Прозрачный - Сегмент Internet сам может быть сегментирован на уровне MAC, например, коммутатором. Прозрачность проявляется в том, что маршрутизатор, работающий на уровне IP, не должен заботиться об этом; в частности, IP-маршрутизатор никогда не пропускает broadcast сообщения (в отличие от multicast), но broadcast сообщения должны свободно распространяться по всей локальной сети сети - это нужно, в частности, для протокола ARP.


Последовательным портом в данном случае называется любой порт, выдающий данные побайтно (асинхронный COM, синхронный RS-232, принтерный LPT) в отличие от сетевого интерфейса, выдающего данные пакетами. Отличается от сетевого тем, что с поиощью последовательных интерфейсов можно связывать напрямую ровно два компьютера, а значит, такой способ не нуждается в адресации пакетов на MAC-уровне.


DNS - Domain Name Service, позволяющий узнать IP-номер и некоторую другую информацию о машине по доменному имени, а также доменное имя по IP-номеру. В частности, зона определения имени по номеру может быть делегирована только на сеть класса A, B или C и никак иначе. :-(


System V:
BSD: ifconfig ep0 inet адрес netmask маска
Linux: ifconfig eth0 inet адрес netmask маска
BSD: ifconfig интерфейс inet адрес netmask маска alias
Linux: ifconfig eth0:1 inet адрес netmask маска
BSD: route add -net номер -netmask маска шлюз
Linux: route add -net номер netmask маска шлюз
Соответствие между интерфейсом eth0 и парой Port/IRQ записано в /etc/lilo.conf; после изменения надо запустить еще что-то.
Windows 3.11

	ifconfig интерфейс inet адрес netmask маска

прописывается в "Свойствах TCP/IP" данного интерфейса.

	ifconfig интерфейс inet адрес netmask маска alias

прописывается в "Дополнительных свойствах".

	route add default шлюз

задается как "Default Gateway".

	route add -net номер -netmask маска шлюз

вводится с командной строки

	route add номер MASK маска шлюз


Эти команды реально выполняются, однако, как правило, они задаются иначе. В файле /etc/sysconfig пишется


	network_interfaces="ep0 lo0"

	ifconfig_ep0="inet 192.168.1.5 netmask 255.255.255.0"

	ifconfig_lo0="inet localhost"

Эти строки обрабатываются файлом /etc/netstart

	# Set up all the network interfaces, calling startup scripts if needed

	for ifn in ${network_interfaces}; do

		eval ifconfig_args=\$ifconfig_${ifn}

		ifconfig ${ifn} ${ifconfig_args}

		ifconfig ${ifn}

	done

	if [ -n "$defaultrouter" -a "x$defaultrouter" != "xNO" ] ; then

		static_routes="default ${static_routes}"

		route_default="default ${defaultrouter}"

	fi

	# Set up any static routes. This should be done before router discovery.

	if [ "x${static_routes}" != "x" ]; then

		for i in ${static_routes}; do

			eval route_args=\$route_${i}

			route add ${route_args}

		done

	fi

а localhost определяется по файлу /etc/hosts, в котором содержится

	127.0.0.1	localhost.домен localhost

и некоторые другие адреса/имена, которые машина должна знать даже в случае недоступности DNS-сервера; как минимум, там кроме loopback содержатся адреса остальных интерфейсов данной машины, ассоциированные с ее доменным именем в полной и короткой формк.


Протокол ARP используется в сетях, имеющих свою собственную нумерацию (Ethernet, TokenRing, X.25) и нужен для того, чтобы не прописывать вручную соответствие IP-адресов номерам сетевых адаптеров. После старта системы таблицы ARP пусты; если приходит IP-пакет от какой-либо станции, фиксируется соответствие ее IP-номера номеру ее сетевой карты. Если надо послать пакет по IP-номеру, для которого неизвестен номер сетевой карты, посылается широковещательное (в понимании локальной сети) сообщение.


Зацикливание пакета в некоторых алгоритмах рассматривается как результат неправильной маршрутизации. Каждый пакет имеет конечное время жизни, задаваемое отправителем и не превышающее 255 секунд, причем каждый маршрутизатор, через который проходил пакет, уменьшает это число как минимум на единицу, а значит пакет не может бесконечно метаться между маршрутизаторами - он умрет и о его смерти известят отправителя отдельным пакетом (на этом основана работа traceroute). Тем не менее некоторые маршрутизаторы во избежание засорения полосы пропускания сами убивают пакеты, которые, судя по их таблицам маршрутизации, следует отправлять через тот интерфейс, через который они пришли.


Протокол DHCP (Dynamic Host Configure Protocol) по запросу машины выдает ей IP-адрес, маску, номер DNS-сервера и т.д. вплоть до загружаемой через сеть операционной системы. Как правило, применяется в варианте, когда запрашивающая машина не знает ни своего адреса, ни адреса DHCP-сервера; в этом случае она находит сервер, посылая широковещательный запрос, а значит, они должны быть в одном сегменте локальной сети.

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...