|
Размер: 16698
Комментарий:
|
← Версия 18 от 2008-10-16 15:48:07 ⇥
Размер: 15930
Комментарий:
|
| Удаления помечены так. | Добавления помечены так. |
| Строка 3: | Строка 3: |
| Команда chroot позволяет выполнять приложения в, так называемом, изолированном окружении. Обычно это используется для запуска служб, требующих привелегий суперпользователя, или приложений, в которых риск наличия уязвимостей достаточно велик. Системный вызов chroot изменяет корневой каталог для процесса,из которого был вызван, и всех потомков данного процесса. После этой операции процесс и его потомки не могут получить доступ к файловой системе за пределами выбранного каталога, кроме как обращаясь к устройствам. Стоит обратить внимание, что изоляция касается исключительно файловой системы. Изоляции процессов в оперативной памяти в данном случае не происходит. | Команда chroot позволяет выполнять приложения в, так называемом, изолированном окружении. Обычно это используется для запуска служб, требующих привелегий суперпользователя, или приложений, в которых риск наличия уязвимостей достаточно велик. Системный вызов chroot изменяет корневой каталог для процесса, из которого был вызван, и всех потомков данного процесса. После этой операции процесс и его потомки не могут получить доступ к файловой системе за пределами выбранного каталога, кроме как обращаясь к устройствам. Стоит обратить внимание, что изоляция касается исключительно файловой системы. Изоляции процессов в оперативной памяти в данном случае не происходит. |
| Строка 5: | Строка 5: |
| В качестве примера рассмотрим DNS-сервер --- BIND. Уязвимости в BIND встречаются достаточно часто, и информация о них небесплатна. Таким образом, BIND потенциально опасен. В документации обычно предполагается, что конфигурационные файлы BIND размещены в /etc и /var. В ALTLinux часть конфигурационных файлов расположена в других каталогах. Естественно, все необходимые для работы каталоги включаются в изолированное окружение, в котором запускается приложение. Корневым каталогом для BIND в ALTLinux является /var/lib. Там находятся все файлы, необходимые для полноценной работы DNS сервера. Так как BIND запускается из обычного окружения, и сначала загружает динамические библиотеки, а затем самостоятельно вызывает chroot, необходимость помещать библиотеки в изолированное окружение отсутствует. |
В качестве примера рассмотрим DNS-сервер --- BIND. Уязвимости в BIND встречаются не очень часто, но получить информацию о них вовремя (заранее) и бесплатно невозможно. Таким образом, BIND потенциально опасен. В документации обычно предполагается, что конфигурационные файлы BIND размещены в `/etc` и `/var`. В ALTLinux часть конфигурационных файлов расположена в других каталогах. Естественно, все необходимые для работы каталоги включаются в изолированное окружение, в котором запускается приложение. Корневым каталогом для BIND в ALTLinux является `/var/lib/bind`. Все файлы, необходимые для полноценной работы DNS сервера, находятся в `/var/lib/bind`. Так как BIND запускается из обычного окружения, и сначала загружает динамические библиотеки, а затем самостоятельно вызывает chroot, необходимость помещать библиотеки в изолированное окружение отсутствует. |
| Строка 10: | Строка 10: |
| Как рассказывалось ранее, DNS служит для преоброзования символьных имен в IP-адреса и обратно. DNS имеет иерархическую структуру. У каждой зоны есть свой DNS-сервер, кроме того, в каждой сети должна быть зарегистрирована служба, преобразующаяся IP-адрес в доменное имя(обратный DNS). | Как рассказывалось ранее, DNS служит для преобразования символьных имен в IP-адреса и обратно. DNS имеет иерархическую структуру. У каждой зоны есть свой DNS-сервер, кроме того, в каждой сети должна быть зарегистрирована служба, преобразующаяся IP-адрес в доменное имя (обратный DNS). |
| Строка 12: | Строка 12: |
| *Домен, зарегистрированный за провайдером. В этом случае вы можете получить поддомены, которые будут связаны с соответствующими IP-адресами.В этом варианте,при необходимсоти изменить доменное имя какой-либо машины, придется обращаться к провайдеру. *Собственный домен. В этом случае провайдер организует лишь обратный DNS. Способов получить собственный домен несколько: *Выбрать незанятое доменное имя и оплатить его аренду у специальной компании-регистратора, после чего информация об этом появится в базе whois. Вы становитесь администратором домена. В этом случае надо обеспечить существование определенного количества "живых" адресов в арендованном домене. Общая стоимость подобного решения составляет около 20 у.е. в год. *Получить поддомен от владельца домена. В большинстве случаев это не требует дополнительных затрат, однако юридическая основа у подобных сделок обычно отсутствует, что не лучшим образом сказывается на ваших правах пользователя поддомена. Часто такой подход используется при регистрации поддоменов для структурных подразделений некоторой организации, например --- po.cs.msu.su. |
* Домен, зарегистрированный за провайдером. В этом случае пользователь получает поддомены, которые будут связаны с соответствующими IP-адресами. При необходимости изменить доменное имя какой-либо машины, придется обращаться к провайдеру. * Собственный домен. В этом случае провайдер организует лишь обратный DNS. Способов получить собственный домен несколько: * Выбрать незанятое доменное имя и оплатить его аренду у специальной компании-регистратора, после чего информация об этом появится в базе whois. Арендатор становится администратором домена. В этом случае надо обеспечить существование определенного количества "живых" адресов в арендованном домене. Общая стоимость подобного решения составляет около 20 у.е. в год. * Получить на непонятных правах поддомен у владельца домена. В большинстве случаев это не требует дополнительных затрат. Часто такой подход используется при регистрации поддоменов для структурных подразделений организаций, например --- po.cs.msu.su. Администратором поддомена можете быть и не вы. При использовании доменного имени желательно (обязательно, в случае собственного домена) обеспечить наличие не менее двух доменных DNS-серверов с существенно различными IP-адресами. |
| Строка 17: | Строка 18: |
| Если задача состоит в организации интранета, например, для школы или компьютерного класса, то необходимости в регистрации доменных имен нет. Можно использовать какой угодно домен, при условии, что не происходит коллизий с уже существующими адресами. | |
| Строка 18: | Строка 20: |
*Получить поддомен. Идете к владельцу домена и на непонятных правах получаете у него поддомен. В большинстве случаев это бесплатно, например когда вы регистрируете поддомен для структурного подразделения компании, владеющей доменом, например, po.cs.msu.su. При этом администратором поддомена можете быть и не вы. В любом случае, вы по хорошему должны обеспечить не меньше двух доменных серверов (в случае с доменом- обязаны обеспечить) с существенно разными IP-адресами, которые бы занимались преобразованием из доменных имён IP-адреса в вашем домене. В случае, если мы имеем дело со школой или с классом, поскольку никаких доменных имён для интранета регистрировать не надо, можно завести какой угодно домен, главное, чтобы не происходило интерференции. Сейчас никакого сервера доменных имён не стоит вообще. Поэтому когда клиенты обращаются за настройками по протоколы DHCP, им передают местонахождение общего сервера. В случае, когда поднят DNS, им передается местонахождение этого DNS сервера, и они будут обращаться к нему, а он дальше. И в этом случае возможно обращаться к локальным компьютерам по именам. |
При наличии в сети DNS-сервера, клиентские машины узнают его адрес при помощи DHCP, и все DNS-запросы посылаются к нему. Таким образом можно организовать обращение по именам к локальным компьютерам. |
| Строка 27: | Строка 23: |
| Это DNS-сервер,изначально предназначенный для того, чтобы запускаться на очень плохих каналах, и предназначенный для принудительного кэширования всех DNS-запросов. То есть, даже если в случае, если сказано, что у записи малое время жизни, всё равно его нужно закешировать. Также он актуален малых сетях без иерархии, и вся задача сводится к тому, чтобы: *снабдить все машины DNS-сервером *учесть все машины |
|
| Строка 31: | Строка 24: |
| Установим его | pdnsd --- это DNS-сервер, изначально предназначенный для того, чтобы запускаться на очень плохих каналах, кэширующий все DNS-запросы, даже запросы к записям с очень малым временем жизни. Кроме того, он весьма удобен в малых сетях без иерархии, когда всё, что необходимо --- это учесть все машины и настроить на них использование внутреннего DNS-сервера. Установим pdnsd: |
| Строка 33: | Строка 28: |
| root@class305 ~]# apt-get install pdnsd | root@demo ~]# apt-get install pdnsd |
| Строка 35: | Строка 30: |
| посмотрим его состав | Посмотрим его состав: |
| Строка 37: | Строка 33: |
| [root@class305 ~]# rpmquery -l pdnsd | [root@demo ~]# rpmquery -l pdnsd |
| Строка 78: | Строка 74: |
| Отредактировав конфигурационный файл pdnsd.conf, запустим его | Запустим (при необходимости можно отредактировать `/etc/pdnsd.conf`, например, чтобы указать отличный от `/etc/hosts` файл для списка соответствий адреса и имени): |
| Строка 80: | Строка 78: |
| [root@class305 ~]# service pdnsd start | [root@demo ~]# service pdnsd start |
| Строка 83: | Строка 81: |
| После этого надо поправить dhcp. | Чтобы начать использовать DNS-сервер осталось лишь отредактировать настройки DHCP. |
| Строка 85: | Строка 83: |
| Для того, чтобы сервер пользовался своим DNS, надо на нем первым nameserver'ом прописать 127.0.0.1 в /etc/resolv.conf | Для того, чтобы DNS-сервер использовал собственный DNS необходимо в качестве первого nameserver в `/etc/resolv.conf` указать 127.0.0.1. |
| Строка 89: | Строка 87: |
| Пакет называется bind, а соответствующий сервис называется named.Один из самых популярных в мире. BIND делают долго и упорно люди из Internet Service consorcium, большинство RFC на этот счёт тоже написаны ими. Этот сервис очень большой и имеет много функций. Запускается он из изолированного окружения /var/lib/bind. |
BIND (Berkeley Internet Name Domain, ранее Berkeley Internet Name Daemon) --- одна из самых функциональных и популярных в мире реализаций DNS-сервера, разарабатываемая Internet Systems Consortium. Большинство RFC по данной тематике разработаны этой же организацией. bind --- имя пакета, соответствующая служба называется named. Запускается BIND из изолированного окружения /var/lib/bind. |
| Строка 93: | Строка 91: |
| [root@class305 ~]# cd /var/lib/bind/ [root@class305 bind]# ls |
[root@demo ~]# cd /var/lib/bind/ [root@demo bind]# ls |
| Строка 98: | Строка 96: |
| В подкаталоге etc лежат настройки. В подкаталоге zone - соответствия между ip-адресами, доменами, почтовыми серверам. Редактировать следует файл local.conf(Учтите что файл написан з соображение что chroot уже сделан) |
В подкаталоге /etc находятся конфигурационные файлы. В подкаталоге /zone размещена информация о зонах --- соответствиях между ip-адресами, доменами, почтовыми серверами, и т.п. Редактировать следует файл local.conf. При это стоит учитывать, что на момент использования этого файла BIND будет работать в изолированном окружении. |
| Строка 101: | Строка 99: |
| Пример зоны можно посмотреть на файле localdomain. | Пример настройки можно посмотреть в файле localdomain. |
| Строка 103: | Строка 101: |
| [root@class305 bind]# cat zone/localdomain | [root@demo bind]# cat zone/localdomain |
| Строка 117: | Строка 115: |
| запись типа SOA определяет различные параметры зоны, такие как время жизни, время обновления и т.п. serial --- такое число, которое надо увел каждый раз, когда изменяется содержимое зоны. Обычная практика - записывать туда дату редактирования. | Запись типа SOA определяет различные параметры зоны, такие как время жизни, время обновления и т.п. `serial` --- число, которое должно увеличиваться каждый раз, когда изменяется содержимое зоны. Обычно в serial указывают дату редактирования. |
| Строка 120: | Строка 118: |
| Аналогично для обратного преобразования, только запись типа PTR а не A. | Аналогично задаётся обратное преобразование: |
| Строка 122: | Строка 120: |
| [root@class305 bind]# cat zone/127.in-addr.arpa | [root@demo bind]# cat zone/127.in-addr.arpa |
| Строка 135: | Строка 133: |
| Устройство обратной зоны ориентированны на сети, и поэтому старший байт справа, а младшие слева, поскольку старшие байты --- сеть, а младшие --- хосты. Обратите внимание, что если у вас локальная сеть, или вообще какая-то сеть, где вы разворачиваете доменный сервер, то вы обязаны редактировать обе зоны (за искл. ситуации, когда добавляете CNAME). Ещё обратите внимание, что далеко не всегда вы сами обеспечиваете обратную зону, поскольку если вы заказали адреса у провайдера, то он должен сам обеспечивать корректность и существование обратной зоны. Есть также некая договорённость о том, как должны поступать провайдеры когда вы хотите сами заниматься обратным преобразованием. Для удобство редактирования, покольку DNS-серверов обычно более одного, один из них объявляется master, а остальные - slave. и они будут скачивать с master конфигурацию. Устроенно это просто: в конфигурационном файле пишете, что он slave, и указываете, адрес master. Тем самым получаются два абсолютно идентичных(с точки зрения внешнего мира) сервера. Так же имеет смысл запретить рекурсивные запросы для всех машин, кроме тех, для которых он создан. |
Устройство обратной зоны ориентировано на сети, и поэтому в названии старший байт находится справа, а младшие слева (так как старшие байты идентифицируют сеть, а младшие --- хосты). |
| Строка 145: | Строка 136: |
| Последнее, что стоит упомянуть: если у вас есть интранет, есть внешняя сеть, и если у вас есть машины, которые снаружи видны под внешним адресом, то неплохо бы чтобы при обращении к DNS серверу за адресом внутренней машины из внутренней сети он выдавал бы её внутренний адрес, а не внешний. Для этого существует технология split horizon, а соответствующее место в документации называется view. | Обратите внимание, что при редактировании зоны, если вы не просто добавляете CNAME, необходимо внести соответствующие изменения и в зону обратного преобразования. Естественно, это надо делать, только если задача обратного DNS решается на этом же сервере. Напомним, что провайдер может предоставлять услугу обратного DNS, и в таком случае заботится о существовании и корректности зоны обратного преобразования должен он. Для удобства конфигурирования нескольких DNS-серверов существует возможность указать один из серверов в качестве основного (master), а все остальные в качестве вторичных, slave-серверов. Slave-серверам задается адрес основного сервера, и в дальнейшем все slave автоматически синхронизируют настройки с master. Таким образом, можно легко организовать несколько DNS-серверов, идентичных с точки зрения внешнего мира. Так же имеет смысл запретить рекурсивные запросы для всех машин, кроме тех, для адресации которых предназначен данный DNS-сервер. DNS предоставляет возможность преобразовывать символьное имя машины в её внутренний или внешний адрес в зависимости от того, откуда поступил запрос. Технология, обеспечивающая эту функциональность, называется split horizon. В BIND она реализована как BIND View Clause. |
| Строка 154: | Строка 151: |
| || 20 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, [[Allena]], MaximByshevskiKonopko || || || | || 90 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, [[Allena]], MaximByshevskiKonopko || || || |
Использование chroot
Команда chroot позволяет выполнять приложения в, так называемом, изолированном окружении. Обычно это используется для запуска служб, требующих привелегий суперпользователя, или приложений, в которых риск наличия уязвимостей достаточно велик. Системный вызов chroot изменяет корневой каталог для процесса, из которого был вызван, и всех потомков данного процесса. После этой операции процесс и его потомки не могут получить доступ к файловой системе за пределами выбранного каталога, кроме как обращаясь к устройствам. Стоит обратить внимание, что изоляция касается исключительно файловой системы. Изоляции процессов в оперативной памяти в данном случае не происходит.
В качестве примера рассмотрим DNS-сервер --- BIND. Уязвимости в BIND встречаются не очень часто, но получить информацию о них вовремя (заранее) и бесплатно невозможно. Таким образом, BIND потенциально опасен. В документации обычно предполагается, что конфигурационные файлы BIND размещены в /etc и /var. В ALTLinux часть конфигурационных файлов расположена в других каталогах. Естественно, все необходимые для работы каталоги включаются в изолированное окружение, в котором запускается приложение. Корневым каталогом для BIND в ALTLinux является /var/lib/bind. Все файлы, необходимые для полноценной работы DNS сервера, находятся в /var/lib/bind. Так как BIND запускается из обычного окружения, и сначала загружает динамические библиотеки, а затем самостоятельно вызывает chroot, необходимость помещать библиотеки в изолированное окружение отсутствует.
Настройка DNS
Как рассказывалось ранее, DNS служит для преобразования символьных имен в IP-адреса и обратно. DNS имеет иерархическую структуру. У каждой зоны есть свой DNS-сервер, кроме того, в каждой сети должна быть зарегистрирована служба, преобразующаяся IP-адрес в доменное имя (обратный DNS). Существует два способа использования доменных имён:
- Домен, зарегистрированный за провайдером. В этом случае пользователь получает поддомены, которые будут связаны с соответствующими IP-адресами. При необходимости изменить доменное имя какой-либо машины, придется обращаться к провайдеру.
- Собственный домен. В этом случае провайдер организует лишь обратный DNS. Способов получить собственный домен несколько:
- Выбрать незанятое доменное имя и оплатить его аренду у специальной компании-регистратора, после чего информация об этом появится в базе whois. Арендатор становится администратором домена. В этом случае надо обеспечить существование определенного количества "живых" адресов в арендованном домене. Общая стоимость подобного решения составляет около 20 у.е. в год.
- Получить на непонятных правах поддомен у владельца домена. В большинстве случаев это не требует дополнительных затрат. Часто такой подход используется при регистрации поддоменов для структурных подразделений организаций, например --- po.cs.msu.su. Администратором поддомена можете быть и не вы.
При использовании доменного имени желательно (обязательно, в случае собственного домена) обеспечить наличие не менее двух доменных DNS-серверов с существенно различными IP-адресами.
Если задача состоит в организации интранета, например, для школы или компьютерного класса, то необходимости в регистрации доменных имен нет. Можно использовать какой угодно домен, при условии, что не происходит коллизий с уже существующими адресами.
При наличии в сети DNS-сервера, клиентские машины узнают его адрес при помощи DHCP, и все DNS-запросы посылаются к нему. Таким образом можно организовать обращение по именам к локальным компьютерам.
pdnsd
pdnsd --- это DNS-сервер, изначально предназначенный для того, чтобы запускаться на очень плохих каналах, кэширующий все DNS-запросы, даже запросы к записям с очень малым временем жизни. Кроме того, он весьма удобен в малых сетях без иерархии, когда всё, что необходимо --- это учесть все машины и настроить на них использование внутреннего DNS-сервера.
Установим pdnsd:
root@demo ~]# apt-get install pdnsd
Посмотрим его состав:
[root@demo ~]# rpmquery -l pdnsd /etc/pdnsd.conf /etc/ppp/ip-up.d/0pdnsd /etc/rc.d/init.d/pdnsd /usr/sbin/pdnsd /usr/sbin/pdnsd-ctl /usr/share/doc/pdnsd-1.2.5 /usr/share/doc/pdnsd-1.2.5/AUTHORS /usr/share/doc/pdnsd-1.2.5/COPYING.BSD /usr/share/doc/pdnsd-1.2.5/ChangeLog /usr/share/doc/pdnsd-1.2.5/ChangeLog.old /usr/share/doc/pdnsd-1.2.5/NEWS /usr/share/doc/pdnsd-1.2.5/README /usr/share/doc/pdnsd-1.2.5/README.ALT /usr/share/doc/pdnsd-1.2.5/README.par /usr/share/doc/pdnsd-1.2.5/README.par.old /usr/share/doc/pdnsd-1.2.5/THANKS /usr/share/doc/pdnsd-1.2.5/TODO /usr/share/doc/pdnsd-1.2.5/contrib /usr/share/doc/pdnsd-1.2.5/contrib/README /usr/share/doc/pdnsd-1.2.5/contrib/change_pdnsd_server_ip.pl /usr/share/doc/pdnsd-1.2.5/contrib/dhcp2pdnsd /usr/share/doc/pdnsd-1.2.5/contrib/pdnsd_dhcp.pl /usr/share/doc/pdnsd-1.2.5/html /usr/share/doc/pdnsd-1.2.5/html/dl.html /usr/share/doc/pdnsd-1.2.5/html/doc.html /usr/share/doc/pdnsd-1.2.5/html/faq.html /usr/share/doc/pdnsd-1.2.5/html/index.html /usr/share/doc/pdnsd-1.2.5/pdnsd.conf /usr/share/doc/pdnsd-1.2.5/txt /usr/share/doc/pdnsd-1.2.5/txt/faq.txt /usr/share/doc/pdnsd-1.2.5/txt/intro.txt /usr/share/doc/pdnsd-1.2.5/txt/manual.txt /usr/share/man/man5/pdnsd.conf.5.bz2 /usr/share/man/man8/pdnsd-ctl.8.gz /usr/share/man/man8/pdnsd.8.gz /var/cache/pdnsd /var/cache/pdnsd/pdnsd.cache /var/run/pdnsd /var/run/pdnsd/socket
Запустим (при необходимости можно отредактировать /etc/pdnsd.conf, например, чтобы указать отличный от /etc/hosts файл для списка соответствий адреса и имени):
[root@demo ~]# service pdnsd start
Чтобы начать использовать DNS-сервер осталось лишь отредактировать настройки DHCP.
Для того, чтобы DNS-сервер использовал собственный DNS необходимо в качестве первого nameserver в /etc/resolv.conf указать 127.0.0.1.
BIND
BIND (Berkeley Internet Name Domain, ранее Berkeley Internet Name Daemon) --- одна из самых функциональных и популярных в мире реализаций DNS-сервера, разарабатываемая Internet Systems Consortium. Большинство RFC по данной тематике разработаны этой же организацией. bind --- имя пакета, соответствующая служба называется named. Запускается BIND из изолированного окружения /var/lib/bind.
[root@demo ~]# cd /var/lib/bind/ [root@demo bind]# ls dev etc var zone
В подкаталоге /etc находятся конфигурационные файлы. В подкаталоге /zone размещена информация о зонах --- соответствиях между ip-адресами, доменами, почтовыми серверами, и т.п. Редактировать следует файл local.conf. При это стоит учитывать, что на момент использования этого файла BIND будет работать в изолированном окружении.
Пример настройки можно посмотреть в файле localdomain.
[root@demo bind]# cat zone/localdomain
$TTL 1D
@ IN SOA localhost. root.localhost. (
2008070800 ; serial
12H ; refresh
1H ; retry
1W ; expire
1H ; ncache
)
IN NS localhost.
IN A 127.0.0.0
localhost IN CNAME localhost.Запись типа SOA определяет различные параметры зоны, такие как время жизни, время обновления и т.п. serial --- число, которое должно увеличиваться каждый раз, когда изменяется содержимое зоны. Обычно в serial указывают дату редактирования.
Аналогично задаётся обратное преобразование:
[root@demo bind]# cat zone/127.in-addr.arpa
$TTL 1D
@ IN SOA localhost. root.localhost. (
2008070800 ; serial
12H ; refresh
1H ; retry
1W ; expire
1H ; ncache
)
IN NS localhost.
0.0.0 IN PTR localdomain.
1.0.0 IN PTR localhost.Устройство обратной зоны ориентировано на сети, и поэтому в названии старший байт находится справа, а младшие слева (так как старшие байты идентифицируют сеть, а младшие --- хосты).
Обратите внимание, что при редактировании зоны, если вы не просто добавляете CNAME, необходимо внести соответствующие изменения и в зону обратного преобразования. Естественно, это надо делать, только если задача обратного DNS решается на этом же сервере. Напомним, что провайдер может предоставлять услугу обратного DNS, и в таком случае заботится о существовании и корректности зоны обратного преобразования должен он.
Для удобства конфигурирования нескольких DNS-серверов существует возможность указать один из серверов в качестве основного (master), а все остальные в качестве вторичных, slave-серверов. Slave-серверам задается адрес основного сервера, и в дальнейшем все slave автоматически синхронизируют настройки с master. Таким образом, можно легко организовать несколько DNS-серверов, идентичных с точки зрения внешнего мира.
Так же имеет смысл запретить рекурсивные запросы для всех машин, кроме тех, для адресации которых предназначен данный DNS-сервер.
DNS предоставляет возможность преобразовывать символьное имя машины в её внутренний или внешний адрес в зависимости от того, откуда поступил запрос. Технология, обеспечивающая эту функциональность, называется split horizon. В BIND она реализована как BIND View Clause.
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
End date |
90 |
1 |
1 |
1 |
|
1 |
|
|