В целом, vsftpd безопаснее чем proftpd, поэтому будем ставить его.
yum -y install vsftpd
chkconfig vsftpd on
service vsftpd start
Со штатными настройками будет пускать пользователей, имеющих аккаунты в системе, с их паролями.
! по умолчанию разрешены анонимные логины!
Возможно изменить штатное поведение и авторизовывать не только системных пользователей, но и по спец списку. Формально они тогда будут работать от заданного пользователя типа ftpuser.
Не забываем, что это настраивается через pam, в /etc/pam.d/vsftpd
Штатный файл:
#%PAM-1.0
session optional pam_keyinit.so force revoke
auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed
auth required pam_shells.so
auth include system-auth
account include system-auth
session include system-auth
session required pam_loginuid.so
BDB
Для авторизации через db - лучше создать отдельный файл и его задать в конфиге
/etc/pam.d/vsftpd-db
Выбор pam-конфига через pam_service_name=vsftpd-db
session optional pam_keyinit.so force revoke
auth required /lib64/security/pam_userdb.so debug db=/etc/vsftpd/login
account required /lib64/security/pam_userdb.so debug db=/etc/vsftpd/login
При этом файл с паролями будет в /etc/vsftpd/login.db
Формат файла-оригинала (login.txt):
юзер1
пароль1
юзер2
пароль2
(перевод строки в конце. Без него может не работать!)
Генерация файла паролей:
db_load -T -t hash -f login.txt /etc/vsftpd/login.db
подробнее
Через MySQL
ставим pam_mysql
/etc/pam.d/vsftpd-mysql
auth required pam_mysql.so user=vsftpd passwd=ftpdpass host=localhost db=vsftpd table=accounts usercolumn=username passwdcolumn=pass crypt=2 account required pam_mysql.so user=vsftpd passwd=ftpdpass host=localhost db=vsftpd table=accounts usercolumn=username passwdcolumn=pass crypt=2
Проверить работу mysql, добавить базу и пользователя
CREATE DATABASE vsftpd;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP ON vsftpd.* TO 'vsftpd'@'localhost' IDENTIFIED BY 'ftpdpass';
FLUSH PRIVILEGES;
Создаем таблицу:
CREATE TABLE 'accounts' ( 'id' INT NOT NULL AUTO_INCREMENT PRIMARY KEY , 'username' VARCHAR(30) NOT NULL , 'pass' VARCHAR( 50 ) NOT NULL , UNIQUE ( 'username' ) ) ENGINE = MYISAM ;
quit;
Добавить системного пользователя
vsftpd:*:1003:1003:User &:/home/vsftpd:/sbin/nologin
Добавление пользователя
#mysql -u root
USE vsftpd;
INSERT INTO accounts (username, pass) VALUES(’testuser’, PASSWORD(’secret’));
quit;
Подробнее
Опций там довольно много и доточка "под себя" может спокойно занять и неделю и больше.
пятница, 12 августа 2011 г.
четверг, 11 августа 2011 г.
Google mail for domains: теперь только 10 ящиков
Имеется в виду бесплатных. Но для нас google apps невыгоден - $50 в год за ящик.
Starting on May 10, new organizations (excluding schools and non-profits) with more than 10 users will need to sign up for our paid service, Google Apps for Business
http://googleenterprise.blogspot.com/2011/04/helping-small-businesses-start-and.html
Увы.
https://www.google.com/a/cpanel/standard/new3?hl=ru&source=gafb-pricing-tabletop-ru
Starting on May 10, new organizations (excluding schools and non-profits) with more than 10 users will need to sign up for our paid service, Google Apps for Business
http://googleenterprise.blogspot.com/2011/04/helping-small-businesses-start-and.html
Увы.
https://www.google.com/a/cpanel/standard/new3?hl=ru&source=gafb-pricing-tabletop-ru
NetApp WAFL
"NetApp WAFL (Write Anywhere File Layout) – это структура размещения произвольно расположенных данных на диске, оптимизированная на производительность доступа к ним."
http://blog.aboutnetapp.ru/archives/863
Утверждение HP:
“Первичные данные (здесь и далее я буду переводить слово primary как “первичные”, этим словом принято называть основные, активные, “боевые” данные приложений, в противоположность данным резервных копий и архивов, например. Прим. romx) имеют случайный характер доступа по своей природе. Дедупликация приводит к тому, что различные блоки данных записываются в различные места диска. NetApp WAFL усугубляет проблему, записывая данные в свободные места, ближайшие к головке записи дисков. Чтение данных вызывает пересборку этих блоков, в формат пригодный для чтения приложением. Оверхед, вызываемый этой пересборкой данных, оказывает влияние на производительность, обычно на 20-50%”
Ответ Dr.Dedupe:
NetApp WAFL (Write Anywhere File Layout) – это структура размещения произвольно расположенных данных на диске, оптимизированная на производительность доступа к ним. Дедупликация еще более “рандомизирует” эту структуру, переназначая указатели на блоки данных и удаляя дубликаты. После дедупликации производительность на чтении иногда слегка возрастает, иногда слегка падает, однако подавляющее большинство пользователей говорят, что не заметили никакой разницы вообще. Важным моментом является то, что мы не перемещаем данные как таковые, просто переставляем на их блоки указатели. Если вы хотите получше разобраться в том, как работает наша технология, то я рекомендую посмотреть пример работы дедупликации.
http://blogs.netapp.com/drdedupe/2010/04/how-netapp-deduplication-works.html#tp
Откуда вообще берется фрагментация?
http://blog.aboutnetapp.ru/archives/881
О “дефрагментации”
http://blog.aboutnetapp.ru/archives/874
Ради создания хотя бы иллюзии одновременности и организуется кэш на запись. Приложения записывают свои данные в кэш записи, получают сразу же ответ "готово" и идут сочинять новые блоки на запись, не дожидаясь того, что данные физически поместятся на диск.
Кэш же внутри себя удерживает блок, ожидая подходящего момента на запись, а также оптимизирует записи, с тем, чтобы уменьшить "пробег" магнитных головок по диску, и возможно оптимальным образом перекомпонует записи так, чтобы уложить их максимально эффективным, с точки зрения head seek-а, способом.
Принципиальное отличие WAFL тут состоит в том, что WAFL не перезаписывает блоки уже записанные на диске, и значит при записи клиенты гораздо меньше ожидают seek-а. Вы помните, что в WAFL записи можно провести "чохом", в выделенный сегмент, а не переписывать по одному блоку, мечась по всему диску, здесь и там, ожидая, когда подъедет под головку тот или иной блок. Поэтому даже без традиционного кэширования записи на WAFL клиентские записи быстро оказываются на дисках.
Строго говоря, большой кэш означает, что, используя транспортную аналогию, записи быстро встают в очередь на посадку, но совсем не значит, что при этом они быстро сядут и поедут.
WAFL оптимизирован именно на минимальное время от момента прихода данных "на остановку" и до входа их "в автобус" жесткого диска, превращая записи в записи последовательного порядка (sequental) из поступающих записей в произвольном порядке (random).
...
Вот почему NetApp Flash Cache не используется на запись данных, работая всем своим объемом только на чтение. Вот почему необходимость кэширования записи для WAFL не столь безоговорочна, как для "классических" дисковых структур.
http://blog.aboutnetapp.ru/archives/936
Таким образом, WAFL сделана "для реального применения" в сферах, где много случайной записи. Но при таком подходе один из самых "неудачных" тестов будет... линейное чтение! Потому что системе придётся много бегать головами для сборки "кусочков". В такой системе обязан быть дефрагментатор, явный или коссвенный, в виде кэша SSD, который сбросит весь файл в новое место большим куском. (разумеется, это будет не дефрагментатор системы, который ничего не знает про реальное расположение данных)
И требуется большая глубина кэша чтения, чтобы максимально эффективно собирать данные по всем дискам.
В целом, для типового применения, а также БД - система хорошая. Но не систем видеомонтажа с линейной записью и чтением и подобными.
Как таковой кэш записи всё-равно может ускорить работу, хоть и многократно эффективнее на классических системах, тут позволит не просто "записали куда получилось", а выбрать оптимальные участки и дождаться, когда будем рядом. К тому же, "прямо под головкой" могут уже быть данные. Писать в "окна" между данными? Вообще каша получится. Ждать достаточно большого окна? Терять преимущество перед другими системами.
Дополнение
Из моей старой заметки, Почему я считаю, что WAFL это не файловая система?
http://blog.aboutnetapp.ru/archives/863
Утверждение HP:
“Первичные данные (здесь и далее я буду переводить слово primary как “первичные”, этим словом принято называть основные, активные, “боевые” данные приложений, в противоположность данным резервных копий и архивов, например. Прим. romx) имеют случайный характер доступа по своей природе. Дедупликация приводит к тому, что различные блоки данных записываются в различные места диска. NetApp WAFL усугубляет проблему, записывая данные в свободные места, ближайшие к головке записи дисков. Чтение данных вызывает пересборку этих блоков, в формат пригодный для чтения приложением. Оверхед, вызываемый этой пересборкой данных, оказывает влияние на производительность, обычно на 20-50%”
Ответ Dr.Dedupe:
NetApp WAFL (Write Anywhere File Layout) – это структура размещения произвольно расположенных данных на диске, оптимизированная на производительность доступа к ним. Дедупликация еще более “рандомизирует” эту структуру, переназначая указатели на блоки данных и удаляя дубликаты. После дедупликации производительность на чтении иногда слегка возрастает, иногда слегка падает, однако подавляющее большинство пользователей говорят, что не заметили никакой разницы вообще. Важным моментом является то, что мы не перемещаем данные как таковые, просто переставляем на их блоки указатели. Если вы хотите получше разобраться в том, как работает наша технология, то я рекомендую посмотреть пример работы дедупликации.
http://blogs.netapp.com/drdedupe/2010/04/how-netapp-deduplication-works.html#tp
Откуда вообще берется фрагментация?
http://blog.aboutnetapp.ru/archives/881
О “дефрагментации”
http://blog.aboutnetapp.ru/archives/874
Ради создания хотя бы иллюзии одновременности и организуется кэш на запись. Приложения записывают свои данные в кэш записи, получают сразу же ответ "готово" и идут сочинять новые блоки на запись, не дожидаясь того, что данные физически поместятся на диск.
Кэш же внутри себя удерживает блок, ожидая подходящего момента на запись, а также оптимизирует записи, с тем, чтобы уменьшить "пробег" магнитных головок по диску, и возможно оптимальным образом перекомпонует записи так, чтобы уложить их максимально эффективным, с точки зрения head seek-а, способом.
Принципиальное отличие WAFL тут состоит в том, что WAFL не перезаписывает блоки уже записанные на диске, и значит при записи клиенты гораздо меньше ожидают seek-а. Вы помните, что в WAFL записи можно провести "чохом", в выделенный сегмент, а не переписывать по одному блоку, мечась по всему диску, здесь и там, ожидая, когда подъедет под головку тот или иной блок. Поэтому даже без традиционного кэширования записи на WAFL клиентские записи быстро оказываются на дисках.
Строго говоря, большой кэш означает, что, используя транспортную аналогию, записи быстро встают в очередь на посадку, но совсем не значит, что при этом они быстро сядут и поедут.
WAFL оптимизирован именно на минимальное время от момента прихода данных "на остановку" и до входа их "в автобус" жесткого диска, превращая записи в записи последовательного порядка (sequental) из поступающих записей в произвольном порядке (random).
...
Вот почему NetApp Flash Cache не используется на запись данных, работая всем своим объемом только на чтение. Вот почему необходимость кэширования записи для WAFL не столь безоговорочна, как для "классических" дисковых структур.
http://blog.aboutnetapp.ru/archives/936
Таким образом, WAFL сделана "для реального применения" в сферах, где много случайной записи. Но при таком подходе один из самых "неудачных" тестов будет... линейное чтение! Потому что системе придётся много бегать головами для сборки "кусочков". В такой системе обязан быть дефрагментатор, явный или коссвенный, в виде кэша SSD, который сбросит весь файл в новое место большим куском. (разумеется, это будет не дефрагментатор системы, который ничего не знает про реальное расположение данных)
И требуется большая глубина кэша чтения, чтобы максимально эффективно собирать данные по всем дискам.
В целом, для типового применения, а также БД - система хорошая. Но не систем видеомонтажа с линейной записью и чтением и подобными.
Как таковой кэш записи всё-равно может ускорить работу, хоть и многократно эффективнее на классических системах, тут позволит не просто "записали куда получилось", а выбрать оптимальные участки и дождаться, когда будем рядом. К тому же, "прямо под головкой" могут уже быть данные. Писать в "окна" между данными? Вообще каша получится. Ждать достаточно большого окна? Терять преимущество перед другими системами.
Дополнение
Из моей старой заметки, Почему я считаю, что WAFL это не файловая система?
среда, 10 августа 2011 г.
Архитектуры разных проектов
http://www.insight-it.ru/masshtabiruemost/arkhitektura-twitter-dva-goda-spustya/
Архитектура Twitter. Два года спустя
http://myforce.ru/arhitektura/arxitektura-instagram/
Архитектура Instagram
Архитектура Twitter. Два года спустя
http://myforce.ru/arhitektura/arxitektura-instagram/
Архитектура Instagram
вторник, 9 августа 2011 г.
XenServer на малом количестве памяти
Собрал тестлабу на бытовом компе, поставил диск с системой - самопроизвольно ребутился. Вставил новый диск, запустил инсталлер и получил
Panic on CPU0:
Not enougth RAM for DOM0 reservation.
Дело в том, что там стояло 512мб озу (да, мало, но по идее достаточно, чтобы просто поставить систему).
На 2 гб - нормально.
Panic on CPU0:
Not enougth RAM for DOM0 reservation.
Дело в том, что там стояло 512мб озу (да, мало, но по идее достаточно, чтобы просто поставить систему).
На 2 гб - нормально.
NetApp E-series, краткий FAQ
Прошло 3 месяца <заметка 27 июня 2011> с момента объявления о покупке NetApp-ом у LSI его подразделения про разработке и продаже внешних дисковых систем, которое было известно под именем Engenio (ESG).
Я не собирался к этой теме возвращаться (по крайней мере часто), как и вообще к теме FC-систем "традиционной архитектуры", которые приобрела, вместе с Engenio, NetApp, так как, в целом, лично мне, они не очень интересны.
К сожалению, я обратил внимание, что в рунете вокруг этой истории раздулся какой-то непонятно-скандальный "ажиотаж", и возникло много непонимания, поэтому я, этим постом, постараюсь ответить на основные вопросы, развеять слухи и заблуждения, вокруг этой истории возникшие.
http://blog.aboutnetapp.ru/archives/945
Я не собирался к этой теме возвращаться (по крайней мере часто), как и вообще к теме FC-систем "традиционной архитектуры", которые приобрела, вместе с Engenio, NetApp, так как, в целом, лично мне, они не очень интересны.
К сожалению, я обратил внимание, что в рунете вокруг этой истории раздулся какой-то непонятно-скандальный "ажиотаж", и возникло много непонимания, поэтому я, этим постом, постараюсь ответить на основные вопросы, развеять слухи и заблуждения, вокруг этой истории возникшие.
http://blog.aboutnetapp.ru/archives/945
Интерфейс SAS-2 и контроллер LSI SAS 9211-8i
Знакомство с интерфейсом Serial Attached SCSI на 6 Гбит/с
http://www.ixbt.com/storage/lsi-sas9211-8i.shtml
http://www.ixbt.com/storage/lsi-sas9211-8i.shtml
Подключение существующего ssl сертификата в ISPManager
Чтобы подключить сертификат (неважно, через панель или руками в конфиге Apache) необходимо иметь сам сертификат и ключ.
Их следует указывать в ISPmanager в меню SSL сертификаты на уровне пользователя как "существующий" сертификат и затем там же активировать.
http://forum.ispsystem.com/ru/showthread.php?t=16016
Похоже, тут ключевой момент "на уровне пользователя".
Ошибочная инструкция по SSL-сертификатам
От рута даже не пытайтесь, при попытке включения будет ошибка "Пользователь не существует".
Их следует указывать в ISPmanager в меню SSL сертификаты на уровне пользователя как "существующий" сертификат и затем там же активировать.
http://forum.ispsystem.com/ru/showthread.php?t=16016
Похоже, тут ключевой момент "на уровне пользователя".
Ошибочная инструкция по SSL-сертификатам
От рута даже не пытайтесь, при попытке включения будет ошибка "Пользователь не существует".
понедельник, 8 августа 2011 г.
воскресенье, 7 августа 2011 г.
наборы от Gumstix
"Пока все только говорят о использовании ARM на серверах, Gumstix сделал платформу для ARM серверов."
http://habrahabr.ru/blogs/server_side_optimization/103430/
Плата позволяет установить 7 модулей Overo с процессором TI OMAP 3503 (ARM Cortex-A8) 600Mhz-720Mhz, памятью 256MB и 256MB NAND флеша. Объединяются модули при помощи встроенного свитча на 9 портов 10/100Mbit, USB-serial для подключения к консолям модулей, 7 USB портов которые могут работать как в OTG режиме так и в host и ethernet порта 10/100Mbit для связи с внешним миром. При этом размер платы составляет 70мм на 293мм, в качестве источника питания выступает блок на 5 вольт и мощностью в 20 ватт.
Стоимость модуля Overo Earth — 149 долларов.
Стоимость платы Stagecoach — 229 долларов.
Суммарная стоимость полного комплекта — 1272 доллара
Оптимально для ДЦ как "честные" выделенные сервера. Что-то вроде VPS, но не V.
Размеры 7х30см, высота 15мм.
"Блок питания прилагается на 20Ватт. Согласно этой бумажке процессор потребляет 1.5Ватта при полной нагрузке при наличии DSP и GPU. Откидываем DSP+GPU (в OveroEarch их нет), думаю в пике будет 800мВт-1Вт. В 1U ядер входит 128 штук :)"
Из комментов. там ещё много подробностей.
Есть и отдельные модули расширения
Tobi
An expansion board to provide DVI display, 10/100baseT Ethernet, USB Host, USB OTG, USB console and Stereo Audio to any Overo® COM
$69
Tobi-Duo
An expansion board to embed inside a security or firewall appliance
$79
О продуктах
http://habrahabr.ru/blogs/server_side_optimization/103430/
Плата позволяет установить 7 модулей Overo с процессором TI OMAP 3503 (ARM Cortex-A8) 600Mhz-720Mhz, памятью 256MB и 256MB NAND флеша. Объединяются модули при помощи встроенного свитча на 9 портов 10/100Mbit, USB-serial для подключения к консолям модулей, 7 USB портов которые могут работать как в OTG режиме так и в host и ethernet порта 10/100Mbit для связи с внешним миром. При этом размер платы составляет 70мм на 293мм, в качестве источника питания выступает блок на 5 вольт и мощностью в 20 ватт.
Стоимость модуля Overo Earth — 149 долларов.
Стоимость платы Stagecoach — 229 долларов.
Суммарная стоимость полного комплекта — 1272 доллара
Оптимально для ДЦ как "честные" выделенные сервера. Что-то вроде VPS, но не V.
Размеры 7х30см, высота 15мм.
"Блок питания прилагается на 20Ватт. Согласно этой бумажке процессор потребляет 1.5Ватта при полной нагрузке при наличии DSP и GPU. Откидываем DSP+GPU (в OveroEarch их нет), думаю в пике будет 800мВт-1Вт. В 1U ядер входит 128 штук :)"
Из комментов. там ещё много подробностей.
Есть и отдельные модули расширения
Tobi
An expansion board to provide DVI display, 10/100baseT Ethernet, USB Host, USB OTG, USB console and Stereo Audio to any Overo® COM
$69
Tobi-Duo
An expansion board to embed inside a security or firewall appliance
$79
О продуктах
суббота, 6 августа 2011 г.
Каковы проблемы FreeBSD и пути их решения? [LJ]
Для начала, линки на оригинал.
Часть 1
Часть 2
А теперь сам текст, мало ли что снова с ЖЖ будет...
ЗЫ Комменты там тоже имеет смысл читать, но сюда их копипастить не буду.
Плюс на хабре тема, выделено сравнение с gentoo
ЗЫЫ ветка шетухина
Часть 1
Часть 2
А теперь сам текст, мало ли что снова с ЖЖ будет...
ЗЫ Комменты там тоже имеет смысл читать, но сюда их копипастить не буду.
Плюс на хабре тема, выделено сравнение с gentoo
ЗЫЫ ветка шетухина
вторник, 2 августа 2011 г.
puppet и аналоги
Server Configuration with Puppet
http://www.youtube.com/watch?v=US8ZpjgEhUg
Puppet, система управления конфигурациями
Часть I
Часть II
Также есть chef
"Изначально я сравнивал cfengine и bcfg2, и после поверхностного ознакомления основное отличие, которое я отметил, было в том, что у cfengine описание императивное, а у bcfg2 - декларативное. В том смысле, что у cfengine в конфигах написано, что нужно сделать, _как_ получить какое-то состояние, а у bcfg2 описывается именно конечное состояние, _что_ нужно получить. Насколько я знаю, puppet - это переработанный cfengine, написанный на руби..."
http://www.linux.org.ru/news/doc/4953619
"Для любителей Python связка Puppet и Capistrano заменяется на Bcfg2 и Fabric.
Puppet/Bcfg2 - для системных вещей, Capistrano/Fabric для императивного выкатывания аппликух."
Там же.
"От Chef отказался по причине ужасной документации, автор через два предложения срывается на какую-то другую тему и забывает о чем только что говорил, в итоге плукая по ссылкам я дошел до рекурсии. У меня два дня заняли попытки поставить его из репозитория Debian и я его не поставил. Поверьте мне, я старался :)"
Почему не ruby:
"Python и Perl стоит везде, а Ruby еще нужно ставить. Ну и мне по личным соображениям куда лучше хачить код на Python/Perl/C, чем Ruby. Я сам пользую Puppet и пишу под него модули, дружу его с LDAP, но реально удивлен почему никто не сделает правильный cfengine на Python (хотя есть func, но это немного не то).
Ну вообще там где приходится ставить Ruby под что-то серьезное, то это всегда проблема, потому что всем рибороидам нужен как минимум Ruby Enterprise, а с ним не все так просто как с apt-get update && apt-get upgrade. Основная проблема, что конретно мне и тем кто со мной работает не удобно хачить модули на Ruby (там где этого простого декларативного язычка не хватает), ибо Ruby никогда не был и не будет инструментом системного администратора. Там где не хватает bash есть perl, там где perl не удобен есть python, прокачивать руби не собираюсь, потому что язычок в лучшем случае годится для веб-разработки и так по мелочи, опять же рельсы - всё, другим он нах не уперся."
http://www.youtube.com/watch?v=US8ZpjgEhUg
Puppet, система управления конфигурациями
Часть I
Часть II
Также есть chef
"Изначально я сравнивал cfengine и bcfg2, и после поверхностного ознакомления основное отличие, которое я отметил, было в том, что у cfengine описание императивное, а у bcfg2 - декларативное. В том смысле, что у cfengine в конфигах написано, что нужно сделать, _как_ получить какое-то состояние, а у bcfg2 описывается именно конечное состояние, _что_ нужно получить. Насколько я знаю, puppet - это переработанный cfengine, написанный на руби..."
http://www.linux.org.ru/news/doc/4953619
"Для любителей Python связка Puppet и Capistrano заменяется на Bcfg2 и Fabric.
Puppet/Bcfg2 - для системных вещей, Capistrano/Fabric для императивного выкатывания аппликух."
Там же.
"От Chef отказался по причине ужасной документации, автор через два предложения срывается на какую-то другую тему и забывает о чем только что говорил, в итоге плукая по ссылкам я дошел до рекурсии. У меня два дня заняли попытки поставить его из репозитория Debian и я его не поставил. Поверьте мне, я старался :)"
Почему не ruby:
"Python и Perl стоит везде, а Ruby еще нужно ставить. Ну и мне по личным соображениям куда лучше хачить код на Python/Perl/C, чем Ruby. Я сам пользую Puppet и пишу под него модули, дружу его с LDAP, но реально удивлен почему никто не сделает правильный cfengine на Python (хотя есть func, но это немного не то).
Ну вообще там где приходится ставить Ruby под что-то серьезное, то это всегда проблема, потому что всем рибороидам нужен как минимум Ruby Enterprise, а с ним не все так просто как с apt-get update && apt-get upgrade. Основная проблема, что конретно мне и тем кто со мной работает не удобно хачить модули на Ruby (там где этого простого декларативного язычка не хватает), ибо Ruby никогда не был и не будет инструментом системного администратора. Там где не хватает bash есть perl, там где perl не удобен есть python, прокачивать руби не собираюсь, потому что язычок в лучшем случае годится для веб-разработки и так по мелочи, опять же рельсы - всё, другим он нах не уперся."
Подписаться на:
Сообщения (Atom)