[lang_en]
One of the main tasks of any administrator is to create stable environment for different sorts of businesses. Big part of this task is troubleshooting. There are many different tools in UNIX for system monitoring, but, at my mind, one of the most useful tools is lsof- one of the least-talked-about tools in a UNIX sysadmin’s toolkit. Lsof lists information about files opened by processes. But that’s really an understatement.
Most people forget that, in UNIX, (almost) everything is a file. The OS makes hardware available to applications by way of files in /dev. Kernel, system, memory, device etc. information in made available inside files in /proc. TCP/UDP sockets are sometimes represented internally as files. Even directories are really just files containing other filenames.
Lsof works by examining kernel data-structures and provides a variety of information related to files, pipes, sockets and more.
[/lang_en]
[lang_ru]
Одной из основных задач любого администратора является создание стабильного окружения для выполнения определенных базнес-процессов. Важным элементом этого процесса является поиск неисправностей или каких-либо проблем в системе. В UNIX существует множество утилит для поиска и устранения проблем в системе, но, на мой взгляд, одна из самых полезных таких утилит – lsof – является одним из инструментов администратора, упоминаемых реже всего. Lsof выводит информацию об открытых файлах и открывших их процессах. но это слишком краткое описание.
Большинство людей не знают или забывают, что в UNIX (практически) все является файлом. ОС делает устройства доступнми для приложений при помощи служебных файлов в каталоге /dev. Информация о ядре, системе, памяти, устройствах и т. д. – все это есть в файлах к каталоге /proc. TCP/UDP сокеты часто представляются в программировании как файлы. Даже каталоги – это просто файлы, содержащие списки других файлов.
Lsof работает анализируя структуры данных ядра ОС и представляет различную информацию, относящуюся к файлам, каналам межпроцессного взаимодействия, сокетам и многому другому.
[/lang_ru]
Read the rest of this entry →
[lang_en]
Sometimes, when I speaking with Unix admins, I wondering, that they did not know anything about very useful UNIX tool – Screen window manager. That is why i decided to describe how I am using it in my job.
[/lang_en]
[lang_ru]
Иногда, общаясь с Unix-администраторами, я удивляюсь, слыша о том, что они не знают ничего об очень полезной UNIX-утилите – оконном менеджере Screen. Вот почему я решил рассказать здесь о том, как я использую его в своей повседневной работе.
[/lang_ru]
Read the rest of this entry →
[lang_en]
I really like Debian and Debian-based Linux distributions. That is because I am admin and I am lazy as all good system administrators 😉 With apt-get based distributions I can install/update/deinstall system packages very fast and my work becomes very efficient (there is no rpm-hell or constant building of new software or software updates).
Today I dugg very useful primer for apt-get/dpkg users. It contains many real-life examples of work with apt-get and dpkg utilities and may be interesting for new debian administrators.
[/lang_en]
[lang_ru]
Я очень люблю Debian и основанные на нем дистрибутивы Linux. Люблю я их потому, что я админ и, как все хорошие системные администраторы, я ленив. 😉 В дистрибутивах, основанных на apt-get я без проблем могу быстро устанавливать/обновлять/удалять пакеты ПО из системы и моя работа становится очень эффективной (нет никакого rpm-hell или постоянного компилирования нового софта или апдейтов).
Сегодня я нашел на digg.com очень полезный справочник для пользователей apt-get/dpkg. Он содержит много реальных примеров того, что может понадобиться в работе с утилитами apt-get и dpkg и может быть полезным и интересным для новоиспеченных Debian-администраторов.
[/lang_ru]
[lang_en]
In one of my last posts about cheap hosting unlimited number of domains, I have described how to point your domain to some sub-directory of an existing hosting account. But sometimes hosting provider requires parking of your DNS name for creating aliases in hosting account. For example, hosting platform, created by me and used on Free Adult hosting Servik.com service, requires your domain’s NS-records to be directed to provider’s own DNS-servers. What can you do if you don’t want to park entire domain to provider’s DNS-servers and want to host only one sub-domain on its servers?
As a simple, but very powerful solution, I can suggest following trick.
Let’s see to generic DNS-domain configuration. Generic domain has following records:
- SOA – record with domain contact information, expiring values, etc.
- NS – record(s) with IP addresses of domain’s DNS-servers.
- MX – record(s) with IP or symbolic names of domain’s mail servers.
- A – record(s) with IP addresses of domain and subdomains.
- CNAME – synonyms for A-records.
When you asking your DNS system for resolving some symbolic name to an IP address and this name is some sub-domain name (such as kovyrin.net or mail.google.com), your DNS server trying to find NS-records for this sub-domain (e.g kovyrin.net) and then, if records were not found, it looks for NS servers for parent domain (kovyrin.net). With generic DNS configuration you can’t allow DNS-management of some sub-domain to off-site DNS-server. You can only move entire domain between DNS-servers.
But let’s try to add following records to your DNS-zone:
....
subdomain.domain.com IN NS off-site.dns-server.com.
....
Now, all requests for subdomain.domain.com will be referred to off-site.dns-server.com and this server can freely manage delegated subdomain record by creating another sub-domains or changing this subdomain IP-address.
[/lang_en]
[lang_ru]
В одном из моих предыдущих постов я рассказывал о дешевом способе хостинга неограниченного количества доменов на одном хостинг-аккаунте. Но иногда хостинг-провайдеры требуют, чтобы парковку домен, который будет использоваться для алиасов, был припаркован на DNS-серверах провайдера. Для примера, хостинговая платформа, созданная мной и используемая на сервисе Free Adult hosting Servik.com требует, чтобы пользовательские NS-записи указывали на собственные сервера провайдера. Что же делать, если Вам не хочется парковать весь домен на сервер провайдера и Вы хотите разместить на их серверах только какой-то один сабдомен?
Существует простое и очень эффективное решение, описанное далее.
Для начала, давайте рассмотрим типичную DNS-конфигурацию. Типичный домен имеет следующие записи:
- SOA – запись, содержащая контактную информацию о домене, а также различные временные характеристики для записей домена.
- NS – записи с IP-адресами для DNS-серверов домена.
- MX – записи, содержащие IP-адреса или символьные имена для почтовых серверов домена.
- A – записи с IP-адресами хостов домена и его сабдоменов.
- CNAME – минонимы для A-записей.
Когда Вы просите свою систему DNS о резолвинге некоторого символьного имени в IP-адрес и это имя оказывается сабдоменом какого-либо домена (как kovyrin.net или mail.google.com), ваш DNS-сервер пытается получить NS-записи для этого сабдомена (например, kovyrin.net) и потом, если такие записи не найдены, он ищет записи для NS-серверов родительского домена (kovyrin.net). В такой приведенной выше типичной конфигурации Вы не сможете передать управление определенным сабдоменом стороннему DNS-серверу. Вы сможете переносить только весь домен между различными DNS-серверами.
Но давайте попробуем добавить следующую запись в Ваше зону:
....
subdomain.domain.com IN NS off-site.dns-server.com.
....
Теперь все записи для subdomain.domain.com будут переправляться к серверу off-site.dns-server.com и этот сервер может свободно манипулировать этим самдоменом и создавать любые А-записи в нем.
[/lang_ru]
[lang_en]
Some times we need to use our existing hosting account to (maybe temporarily) place another web-site in it. But what we can do, if our hosting provider allows only one hosting directory and only aliases for main site (as GoDaddy.com does)? We can use the following Apache+mod_rewrite trick to host unlimited number of domains on one hosting directory.
First of all, we need to point our new domain to hosting server IP. If server’s IP is static, we can do it by simple A-record in our DNS-zone control panel:
new-domain.com IN A IP.ADD.RE.SS
If you don’t know IP address of hosting server or this address is not permanent (for example, because of some load balancing used by hosting provider), you can use simple trick with CNAME-record in your new DNS-zone:
new-domain.com IN CNAME already-hosted-domain.com.
After the first step was finished we have new-domain.com pointed to our hosting provider’s server. Now, we need to add this domain support to hosting server. We can do it by your hosting provider’s “Domain aliases” option or another option with such meaning.
After we have associated our new domain name with existing directory on hosting server (/hosting/dir), everything we need is to do something to force hosting server to use some sub-directory for all requests to new-domain.com (/hosting/dir/new-domain). To do it, we need to put following code into the .htaccess file in /hosting/dir directory:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !^/new-domain/
RewriteCond %{HTTP_HOST} new-domain\.com$
RewriteRule (.*) http://already-hosted-domain.com/new-domain/$1 [L]
That’s all! After we have created this file, all requests to new-domain.com will be pointed to /hosting/dir/new-domain directory.
[/lang_en]
[lang_ru]
Иногда нам бывает нужно использовать существующий хостинг-аккаунт для (возможно, временного) размещения другого сайта на нем. Но что делать, если хостинг-провайдер разрешает создание только одного корневого каталога и привязываение алиасов к каталогу, в котором лежит главный сайт (как это делает, например, компания GoDaddy.com)? Мы можем использовать описанный ниже трюк с Apache+mod_rewrite для размещения неограниченного количества доменов в одном каталоге хостинга.
Для начала, нам нужно, чтобы новый домен указывал на IP-адрес хостингового сервера. Если адрес сервера статичен, мы можем просто сделать A-запись в панели управления нашей DNS-зоной:
new-domain.com IN A IP.ADD.RE.SS
Если Вы не знаете IP-адрес хостингового сервера или этот адрес не постоянен (например, из-за специфичных технологий балансировки нагрузки, используемых Вашим хостинг-провайдером), Вы можете истользовать простой трюк с CNAME-записью в Вашей DNS-зоне:
new-domain.com IN CNAME already-hosted-domain.com.
После завершения первого этапа настройки у нас есть домен new-domain.com, указывающий на используемый хостинг-сервер. Теперь нам необходимо добавить поддержку нашего нового домена к этому серверу. Это можно сделать при помощи опции “Domain aliases” в панели управления хостингом или какой-нибудь другой опции, имеющей такое же значение у используемого хостинг-провайдера.
После того, как мы ассоциировали наше новое доменное имя с существующим каталогом на хостинговом сервере (/hosting/dir), единственное, что нам необходимо сделать – это заставить хостинговый сервер использовать некоторый подкаталог для всех запросов к домену new-domain.com (/hosting/dir/new-domain). Для того, чтобы получить такой эффект, нам нужно создать файл .htaccess в каталоге /hosting/dir и поместить в него следующий код:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !^/new-domain/
RewriteCond %{HTTP_HOST} new-domain\.com$
RewriteRule (.*) http://already-hosted-domain.com/new-domain/$1 [L]
Вот и все! После создания файла все запросы к сайту http://new-domain.com/ будут перенаправляться в каталог /hosting/dir/new-domain.
[/lang_ru]