Книга посвящена дистрибутиву Linux Mint и одной из его главных



Скачать 21.34 Mb.
Pdf просмотр
страница28/30
Дата22.11.2016
Размер21.34 Mb.
Просмотров5912
Скачиваний0
1   ...   22   23   24   25   26   27   28   29   30
Создаём простой пул
Освоив ранее основные понятия, мы научились понимать ZFS. Для обратной же задачи — чтобы ZFS понимала нас — нужно ознакомиться се командами.
Главные из них — две zpool для создания и управления пулами, и zfs для создания и управления наборами данных. Немного, правда Хотя каждая из этих команд включает множество субкоманд, с которыми мы со временем разберёмся.
Очевидно, что работу с ZFS следует начинать с создания пула хранения.
Начнём с этого и мы. В простейшем случае однодисковой конфигурации это делается так zpool create tank dev_name Здесь create — субкоманда очевидного назначня, tank — имя создаваемого пула (оно обычно даётся в примерах, нона самом деле может быть любым — с учётом ограничений ZFS, я использую имя data), а dev_name — имя устройства, включаемого в пул. Каковое может строиться по любой из описанных ранее моделей. И, чтобы не повторяться, напомню все команды по
манипуляции с пулами и наборами данных в них выполняются от лица администратора.
В случае, если в состав пула включается один диски второго не предвидится, можно использовать имя устройства верхнего уровня например, sda для цельного устройства (обратим внимание, что путь к файлу устройства указывать ненужно. Однако реально такая ситуация маловероятна загрузка с ZFS проблематична, так что как минимум потребуется раздел с традиционной файловой системой под /boot (и/или под корень файловой иерархии, так что команда примет вид вроде следующего zpool create data sda3 Однако если можно ожидать в дальнейшем подсоединения новых накопителей и их включения в существующий пул, то лучше воспользоваться именем по модели by-id, например zpool create data ata-Crucial_CT512MX100SSD1_14330CEEA98C-part3 Очевидно, что в случае однодискового пула ни о какой избыточности говорить не приходится. Однако уже при двух дисках возможны варианты.
Первый — создание пула без избыточности zpool create data dev_name1 dev_name2 где dev_name1 и dev_name1 — имена устройств в принятой модели именования.
В приведённом примере будет создано нечто вроде а нулевого уровня,
с расщеплением (stripping) данных на оба устройства. Каковыми могут быть как дисковые разделы, таки диски целиком. Причём, в отличие от диски (или разделы) не обязаны быть одинакового размера.
После указанной команды никаких сообщений не последует. No news —
good news, говорят англичане в данном случае это означает, что пул был благополучно создан. В чём можно немедленно убедиться двумя способами.
Во-первых, в корневом каталоге появляется точка его монтирования /data. А
во-вторых,
этой цели послужит субкоманда status:
# zpool status data которая выведет нечто вроде этого data state: ONLINE scan: none requested config:
NAME STATE READ WRITE CKSUM mypool ONLINE 0 0 0
sdd ONLINE 0 0 0 sdf ONLINE 0 0 0 errors: No known data errors Ас помощью субкоманды list можно узнать объём новообразованного пула zpool list data
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT data 18,9G 93K 18,9G 0% 1.00x ONLINE - Легко видеть, что он равен сумме объёмов обеих флэшек, если
«маркетинговые» гигабайты пересчитать в «настоящие».
К слову сказать, если дать субкоманду list без указания аргумента — имени пула, то она выведет информацию о всех пулах, задействованных в системе. В
моём случае это выглядит так zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT exp 18,9G 93K 18,9G 0% 1.00x ONLINE - data 199G 20,8G 178G 10% 1.00x ONLINE - Обращаю внимание, что даже чисто информационные субкоманды вроде list и status требуют прав администратора.
Разумеется, два пула водной, да ещё и настольной, машине — излишняя роскошь. Так что пул, созданный в экспериментальных целях, подлежит уничтожению, что делается с помощью субкоманды destroy:
# zpool destroy exp После чего он пропадёт из списка пулов. А что можно сделать с пулом до его уничтожения, увидим со временем.
«Избыточные» пулы
Избавившись отставшего ненужным пула, рассмотрим второй вариант создание пула с зеркальным устройством. Создаём его из двух накопителей одинакового объёма:
# zpool create -f exp2 mirror sdf sdg Проверка показывает, что итоговый пул, как и следовало ожидать, равен объёму одного накопителя zpool list mypool

NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT exp2 3,72G 91,5K 3,72G 0% 1.00x ONLINE - При различии объёмов больший диск будет обрезан до объёма меньшего.
Полное зеркалирование любыми, по моему мнению, в настольных условиях роскошь непозволительная банальные бэкапы данных проще и надёжнее.
Тем не менее, не исключаю, что некоторая избыточность на уровне проверки контрольных сумм может оказаться нелишней, да и не столь накладна. Так что давайте посмотрим и на третий вариант пула из более чем одного устройства — Теоретически виртуальное устройство с одинарным контролем чётности,
как уже говорилось, можно создать при наличии двух устройств физических.
Однако практически это оказывается накладно, особенно если устройства неодинакового размера. Поэтому задействуем под него три накопителя zpool create exp3 raidz sdd sdf sdg что даст нам следующую картину zpool list exp3
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT exp3 11,1G 205K 11,1G 0% 1.00x ONLINE - Впрочем, как мне кажется, в настольных условиях не стоит выделки и эта овчинка.
Пул кэшируемый
И, наконец, последний вариант организации пула из более чем одного устройства — создание пула с кэшированием. Для чего создаём из двух устройств простой пул без избыточности и подсоединяем к нему устройство для кэша:
# zpool create exp4 sdd sdf cache sdg Очевидно, что устройство для кэширования не должно входить в пул любого рода — нив простой, нив избыточный. Что мы и видим в выводе субкоманды list:
# zpool list exp4
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT exp4 18,9G 82K 18,9G 0% 1.00x ONLINE - где никаких следов его обнаружить неуда тся. Если же появляются сомнения, а подключилось ли оно на самом деле, обращаемся к субкоманде status, которая покажет беспочвенность наших опасений.
Как я уже говорил в обзоре возможностей ZFS, подключение устройства кэширования имеет смысл при наличии большого традиционного винчестера
или винчестеров) и относительно небольшого SSD, которое и играет роль дискового кэша.
О некоторых опциях команды zpool
Команда zpool поддерживает ещё множество субкоманд, предназначенных для экспорта и импорта пула, добавления к нему устройств и изъятия оных, итак далее. Но сейчас я расскажу о некоторых опциях, которые могут оказаться необходимыми при создании пула.
Одна из важный опций — -f: она предписывает принудительное выполнение данной операции и требуется, например, при создании пула из неразмеченных устройств.
Полезной может оказаться опция -n. Она определяет тестовый режим выполнения определённой субкоманды, то есть выводит результат, например,
субкоманды zpool create без фактического создания пула. И, соответственно,
сообщает об ошибках, если таковые имеются.
Интересна также опция -m mountpoint. Как уже говорилось, при создании пула по умолчанию в корне файловой иерархии создаётся каталог который в дальнейшем будет точкой монтирования файловых систем Возможно, что это окажется не самым лучшим местом для их размещёния, и,
как мы увидим в дальнейшем, это несложно будет изменить. Но можно задать каталог для пула сразу — например, /home/data: это и будет значением опции. Никто не запрещает определить в качестве такового и какой-либо из существующих каталогов, если он пуст, иначе автоматическое монтирование файловых систем пула в него окажется невозможным.
Наконец, нынче важное значение приобретает опция ashift=#, значением которой является размер блока файловой системы в виде степеней двойки. По умолчанию при создании пула размер блока определяется автоматически, и до некоторого времени это было оптимально. Однако затем, с одной стороны,
появились диски так называемого Advanced Format, в других размер блока равен 4 КБ. С другой стороны, получили распространение SSD-накопители,
обычно также имеющие четырёхкилобайтный блок. В этих условиях автоматика ZFS может работать некорректно, что приводит к падению производительности пула.
Для предотвращения означенного безобразия и была придумана опция ashift. Значение её по умолчанию — 0, что соответствует автоматическому определению размера блока. Прочие же возможные значения лежат в диапазоне от 9 для блока в 512 байт (29 = 512) до 16 для 64-килобайтного блока (216 = 65536). В интересующем нас случае четырёхкилобайтного блока оно составляет 12 (212 = 4096). Именно последнее значение и следует указать явным образом при создании пула из винчестеров AF или большинства SSD-накопителей.
Создание файловых систем
Пулы хранения представляют собой вместилища для наборов данных, для манипуляции которыми предназначена вторая из главнейших команд — Самыми важными наборами данных являются файловые системы, к рассмотрению которых мы и переходим.
Для создания файловых систем предназначена субкоманда create команды
zfs, которая требует единственного аргумента — имени создаваемой ФС и обычно не нуждается нив каких опциях zfs create pool_name/fs_name Внутри пула можно создавать сколь угодно сложную иерархию файловых систем. Единственное условие — родительская файловая система для системы более глубокого уровня вложенности должна быть создана заблаговременно. Ниже я покажу это на конкретном примере создания файловых систем внутри каталога /home — наиболее оправданное место для размещёния наборов данных Начну я немножечко издалека. При стандартной установке Mint не обойтись без создания учетной записи обычного пользователя, и, следовательно, в каталоге /home будет присутствовать по крайней мере один подкаталог Смонтировать же файловую систему ZFS в непустой каталог невозможно, и,
значит, мы не можем сразу прибегнуть к опции -m для определения
«постоянной прописки создаваемого пула.
Поэтому для начала делаем для пула прописку во временной точке пусть это будет традиционный /tank:
# zpool create -o ashift=12 tank ata-SanDisk_SDSSDX120GG25_120823400863- part3 ata-SanDisk_SDSSDX120GG25_120823402786-part3 Теперь создаём файловую систему для будущего домашнего каталога zfs create tank/home А внутри жене необходимые дочерние ветви, как то zfs create tank/home/alv которая потом заменит мой домашний каталог — в нём я не держу ничего,
кроме конфигурационных файлов zfs create tank/home/proj это файловая система для моих текущих проектов, итак далее.
Как и было обещано разработчиками ZFS, процедура ничуть не сложнее,
чем создание обычных каталогов. Благодаря этому файловые системы можно легко создавать по мере надобности, для решения какой-либо частной задачи.
И столь же легко уничтожать их, когда задача эта выполнена. Что делается таким образом zfs destroy pool_name/fs_name Использовать субкоманду destroy следует аккуратно никакого запроса на подтверждение при этом не будет. Правда, и уничтожить файловую систему,
занятую в каком-либо текущем процессе, можно только с указанием опции -а файловую систему, содержащую системы дочерние, не получится убить и
таким образом.
Ни в какой специальной операции монтирования новообразованные файловые системы не нуждаются — оно происходит автоматически в момент их создания, о чём свидетельствует следующая команда mount | grep tank tank/home on /tank/home type zfs (rw,atime,xattr)
tank/home/alv on /tank/home/alv type zfs (rw,atime,xattr) tank/home/proj on
/tank/home/proj type zfs (rw,atime,xattr) Для обеспечения монтирования файловых систем ZFS при рестарте машины не требуется и никаких записей в файле /etc/fstab: это также происходит само собой, совершенно нечувствительно для пользователя. Правда, если для файловой системы ZFS определить свойство mountpoint=legacy, то с ней можно управляться и традиционным способом.
Как и для обычного каталога, объём каждой файловой системы ничем не лимитирован, ив момент создания для любой из них потенциально доступно всё пространство пула, которое равномерно уменьшается по мере разрастания файловых систем. На данный момент в моей системе это выглядит так.
Казалось бы, для тех же целей можно ограничиться обычными каталогами.
Однако в наборах данных ZFS мы имеем дело с полноценными файловыми системами, для которых могут быть установлены индивидуальные свойства,
аналогичные опциям монтирования файловых систем традиционных. Чем мы сейчас и займёмся.
Файловые системы устанавливаем свойства
При создании файловая система ZFS получает по умолчанию определённый набор свойств, во многом сходный с атрибутами традиционных файловых систем, определяемыми опциями их монтирования. Полный их список можно получить командой zfs get all fs_name Свойств этих очень много, однако далеко не все они представляют для нас интерес. Важно только помнить, что любое из свойств каждой файловой системы можно поменять с помощью субкоманды set и её параметра вида свойство=значение. Причём изменение свойств для материнской системы рекурсивно распространяется на все дочерние. Однако для любой последней свойства можно изменить в индивидуальном порядке. Что я сейчас и проиллюстрирую на примерах.
Так, абсолютно лишним представляется свойство atime, то есть обновление времени последнего доступа к файлам. Оно, во-первых, снижает быстродействие, с другой — способствует износу накопителей (правда,
нынче и то, и другое чисто символичны. Так что отключаем это свойство для всех файловых систем zfs set atime=off tank/home Аналогичным образом расправляемся и со свойством xattr:
# zfs set xattr=off tank/home
А вот дальше можно заняться и индивидуализацией. Как я уже говорил, в момент создания файловые системы ZFS безразмерны. Если это не подходит, для них можно установить квоты. Однако я этого делать не буду в моём случае это приводит к потере половины смысла ZFS. А вот зарезервировать место для критически важных каталогов, дабы его не отъела, скажем, мультимедиа, известная своей прожорливостью, будет нелишним. И потому я для файловых систем tank/home/proj и tank/home/alv устанавливаю свойство reservation. Для файловой системы проектов оно будет максимальным zfs set reservation=10G tank/home/proj Для остальных ограничусь более скромным гигабайтом резерва.
Далее, поскольку данные в файловой системе tank/home/proj для меня действительно важны, и шутить сними я склонен даже гораздо меньше, чем с дамами, предпринимаю дополнительные меры по их сохранности путём удвоения числа копий (по умолчанию оно равно 1):
# zfs set copies=2 tank/home/proj А для данных не столь важных — тех, что часто проще скачать заново,
нежели отыскать на локальной машине, можно выполнить и обратную операцию — отказаться от подсчёта контрольных сумм zfs set checksum=off tank/home/media Для файловых систем, содержащих хорошо сжимаемые данные (например,
для моего домашнего каталога, где лежат одни файлы, можно включить компрессию zfs set compression=on tank/home/alv Я этого не делал экономия места получается грошовая, а нагрузка на процессор и расход памяти, как говорят, очень приличные. Однако это свойство целесообразно включать в системах с огромными логами, если выделить под них файловую систему в пуле При желании для некоторых файловых систем (например, того же домашнего каталога) можно отключить такие свойства, как exec, setuid,
devices — легко догадаться, что результат будет аналогичен указанию опций монтирования noexec, nosuid, nodev для традиционных файловых файловых систем. И, разумеется, для файловых систем, изменение которых нежелательно, можно придать свойство Все необходимые свойства файловых систем желательно установить до их наполнения контентом, ибо многие из них (например, компрессия) обратной силы не имеют.
Перемонтирование
После создания файловых систем и задания всех необходимых их свойств наступает психологический момент для перемонтирования их по месту
«постоянной прописки — то есть в каталог /home. Что потребует некоторых подготовительных действий.
Поскольку предполагается, что все новообразованные файловые системы должны быть полностью доступны обычному пользователю (то есть мне,
любимому), перво-наперво следует изменить атрибуты из принадлежности ведь создавались они от имени администратора и принадлежат юзеру по имени Для чего даю команду chown -R alv:users Теперь нужно скопировать конфиги из каталога /home/alv вне забыв про опцию -p для сохранения атрибутов.
Все предыдущие операции можно было выполнять, получив права администратора с помощью команды sudo. Причём где угодно — в текстовом виртуальном терминале или в терминальном окне Иксового сеанса. Теперь же потребуется переавторизоваться в голой консоли.
Монтирование файловых систем ZFS в каталог с любым содержимым невозможно, так что требуется очистить каталог /home от следов прежней жизнедеятельности пользователя таким образом rm -Rf /home/alv Прихоть одном активном пользовательском процессе в ответ на это последует сообщение об ошибке. Так что, возможно, перед этим придётся убить все реликтовые процессы, запущенные в Иксах от имени пользователя.
Сначала выявляем их командой ps aux | grep alv обращая внимание на идентификаторы процессов (PID). А затем последовательно мочим их в сортире kill -9 #### Альтернативный способ — разрузка системы в recovery mode с выбором пункта меню root, что в Mint эквивалентно однопользовательскому режиму. В
этом случае никаких пользовательских процессов не будет по определению, и перенос файлов изв можно выполнить напрямую.
Выполнив все указанные действия, определяем для набора данных tank/home свойство mountpoint, что и осуществит перемонтирование zfs set mountpoint=/home tank/home Теперь остаётся только с помощью команды ls убедиться, что в /home появились новые подкаталоги с нужными атрибутами users
48
Sep
23 14:27
alv/
drwxr-xr-x
18
alv users
18
Sep
22 А команда

# mount | grep /home покажет нам новые точки монтирования файловых систем on
/home type zfs
(rw,noatime,noxattr)
tank/home/alv on
/home/alv type zfs
(rw,noatime,noxattr)
tank/home/proj on
/home/proj type На этом дело с подготовкой файловых систем ZFS к практической работе можно считать законченным при перезагрузке машины все они будут благополучно смонтированы в автоматическом режиме.
Подключение пула ZFS, созданного в другой системе
Здесь речь пойдёт о том, как подключить к некоей Linux-системе
(конкретно, Ubuntu) пул ZFS, ранее созданный в другой системе теоретически это могут быть Solaris, FreeBSD или более иной дистрибутив, для которого предусмотрена поддержка ZFS on Linux. Но практически я опробовал только последний вариант, о чём и расскажу.
Перво-наперво нужно перезагрузиться в ту систему, в которой создавался пул (в моём случае это была openSUSE), и экспортировать его командой zpool export data где data — имя пула сточкой монтирования Следующий шаг — вернуться в Ubuntu и создать в ней аналогичную точку монтирования для пула ZFS — в моём случае таким образом sudo mkdir /home/data Дать ей атрибуты принадлежности обычному пользователю sudo chown -R alv:alv /home/data И импортировать созданный в openSUSE пул ZFS:
$ sudo zpool import -f data Не забыв об опции -f, предписывающей принудительной выполнение импорта. Без неё ответом на эту команду будет сообщение об ошибке.
Теперь в каталоге /home/data можно видеть те же самые файловые системы, которые были созданы в родителькой для пула системе, вместе со всеми размещёнными в них данными. С которыми можно начинать работать.
Сказанное справедливо, если идентификаторы пользователя в обеих системах совпадают — в моём случае это именно так. Однако в случае общем это совсем необязательно и тогда надо озаботиться каким-либо способом обеспечения совместного доступа к ним из разных систем. Впрочем, ко которой мы сейчас разговариваем, это не имеет ни малейшего отношения.

Индивидуализация системы
Последний очерк посвящается апофеозу знакомства с дистрибутивом Mint и его Cinnamon — сборке индивидуализированной системы на его основе. Как сказал то ли один из премьер-министров Великобритании, то ли некий президент Франции (кому только это изречение ни приписывали?):
Тот, кто в (информационной) юности не мечтал собрать свой дистрибутива, не имеет сердца. Тот, кто продолжает мечтать об этом в
(информационной) зрелости — не имеет разума.
Однако применительно к Linux Mint вполне возможно сочетать сердечность и разумность даже в преклонные годы, ибо собрать свою индивидуализированную систему на базе этого дистрибутива и простои полезно.
Свой Mint: введение
Во время первого знакомства с су меня сложилось впечатление, что в его инсталляции настолько мало лишних программ, что не стоило и заморачиваться сих удалением. Однако при дальнейшем рассмотрении оказалось, что лишних (для меня) приложений вполне достаточно например, вся мультимедиа. С другой стороны, ряд привычных для меня программ (например, те же мультимединые) приходилось доустанавливать. И
появилась мысль изготовить свой установочный диск этого дистрибутива. На котором не было бы ничего лишнего (повторяю, для меня. И, напротив, были бы все приложения, которые мне так или иначе пришлось доустанавливать.
В сети можно найти упоминания о нескольких инструментах для изготовления собственного дистрибутива на базе Ubuntu и её производных (а, как известно, принадлежит к их числу — утилита командной строки, позволяющая сделать снапшот установленной системы

remastersys — утилита для резервного копирования установленной системы и создания на её базе носителя именно таким образом собирается, например, дистрибутив Matuntu
— отечественный вариант св качестве рабочей среды

Ubuntu Builder-- программа с графическим интерфейсом, позволяющая скомпоновать свой дистрибутив попакетно. Однако первые две показались мне сложноватыми и избыточными для моих целей, а последняя, похоже, прекратила своё развитие — версии её для Trusty, на которой основываются текущие релизы Mint, в PPA- репозитории не обнаружилось.
И в итоге я остановился на программе Ubuntu Customization Kit (далее —
UCK): гугление показало, что это примерно то, что мне нужно, ибо специально предназначается для коррекции состава пакетов в первую очередь.
UCK: обзор
Программа UCK в виде одноимённого пакета имеется в официальном репозитории, и потому может быть установлена любым из стандартных
способов. После этого в секции Администрирование главного меню Cinnamon появляется пункт, который, как ни странно, называется Ubuntu Customization
Kit, через который эту программу и можно запустить. Но прежде чем смотреть, что она после этого делает, попробуем представить, что у неё
внутре.
Всякий, кому приходилось заниматься модификацией существующего установочного образа какого-либо дистрибутива, представляет себе основные этапы этого процесса:

монтирование образа как устройства

развёртывание её файловой системы — нынче все дистрибутивы используют какой-либо механизм компрессии, в частности в убунтоидах это SquashFS; монтирование в систему как связанных (bind) таких служебных,
но абсолютно необходимых каталогов материнской системы, как /dev,
/sys и, на всякий случай, /proc; выполнение операции chroot в каталог, становящийся таким образом корневым выполнение в окружении необходимых действий по удалению ненужных пакетов и установке необходимых выход из окружения и обратная запаковка каталога размонтирование устройства и создание из него загрузочного iso- образа с помощью isolinux. Интуитивно понятно, что UCK не делает ничего иного, кроме перечисленного — он просто автоматизирует описанный процесс, делая его этапы почти незаметными для применителя.
Основные исполняемые файлы пакета uck (а их 16 штук) собраны, понятное дело, в каталоге /usr/bin и имеют префикс uck-*. Все они являются самыми обычными шелл-скриптами, причём по их именам легко догадаться о назначении каждого. Головным, то есть запускающим весь процесс скриптом является /usr/bin/uck-gui — именно он вызывается через пункт меню
Администрирование -> Ubuntu Customization Kit:
А через редактор меню можно посмотреть на его свойства:
По скриншоту можно догадаться о присутствии в строке запуска опции, отвечающей за ожидание нажатия Enter перед выходом из программы после успешного завершения её работы.
Кстати говоря, при неуспешном завершении, то есть возникновении ошибки по любой причине (например, нехватке места на целевом устройстве, ничего не происходит, кроме остановки работы. Никаких возвратов назад не предусмотрено, остаётся только закрывать главное терминальное окно программы (о котором далее) и начинать всё сначала. Так что, учитывая длительность распаковки SquashFS и необходимость удаления образовавшихся в процессе файлов (а их — многие десятки тысяч, что на файловой системе, например, XFS затягивается очень надолго, лучше действовать аккуратно и по возможности не ошибаться.
Команда uck-gui запускается от лица обычного пользователя — пароль для доступа к административным привилегиям запрашивается только тогда,
когда они на самом деле потребуются. Кроме указанной --wait-before-exit, она имеет ещё как минимум две опции. Первая, -m, обеспечивающая кеширование
модифицированных частей образа, работает, как сказано вне всегда, и потому в стандартной ситуации не используется.
Вторая опция также штатно не задействована, но она может оказаться важной для применителя. Это опция remaster-dir, определяющая рабочий каталог для UCK, отличный от умолчального
/tmp. Через редактор меню я переопределил этот каталог как
/data/my-mint, поэтому итоговая команда для запуска UCK через меню приобрела такой вид --wait-before-exit /home/data/my-mint Кроме запуска процесса, сценарий uck-gui отвечает, в том числе, и за выбор типа десктопа — unity, gnome, kde, или others. Однако попытки вносить здесь какие-либо изменения (например, пополнение списка доступных десктопов)
никакого результата за собой не повлекут. То есть добавленные десктопы появятся вменю их выбора, но ничего не изменится.
Потому что на самом деле кроме исполняемых скриптов в каталоге основным компонентом UCK является также каталог /usr/lib/uck/. А в нём,
кроме всего прочего

файл
/usr/lib/uck/customization- profiles/localized_cd/customize, представляющий собой исполняемый шелл- сценарий, который отвечает в том числе и за вызов терминальной программы.
Запомним его — в некоторых случаях он подлежит ручному редактированию.
Впрочем, всё сказанное проще продемонстрировать на примере конкретной сборки своего варианта дистрибутива, чем мы сейчас и займёмся.

Каталог: wp-content -> uploads -> 2016
2016 -> Государственное областное бюджетное
2016 -> В. П. Зинченко писал о том, что если человек в детстве не дополучил некую норму участия в игровом времяпрепровождении, он приобретает социально-психологическую ущербность вроде «игровой дистрофии», которую в последу
2016 -> Общешкольное родительское собрание «Об ответственности родителей за воспитание детей»
2016 -> 1 июня 2016 года Международный день защиты детей 1 июня
2016 -> «Формирование социально-нравственной позиции дошкольников посредством введения сказочных сюжетов в компьютерные дидактические игры»
2016 -> Принята Утверждена
2016 -> Конкурс по разработке компьютерных игр патриотической направленности «патриот by»


Поделитесь с Вашими друзьями:
1   ...   22   23   24   25   26   27   28   29   30


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал