fdisk - редактирование разделов

drBatty написал:

Права вообще локально не очень-то и действуют И ничего я не перегибал - у вас одна стратегия использования смешанного раздела - разрешить всё. И ничего вы не сможете сделать с юзером, который там будет сохранять любые файлы, и менять их права как ему вздумается.

Хотелось бы примеры, как юзер сможет сохранять там любые файлы?
Юзер в своем каталоге /home/user а в каталоге /home уже действуют привелегии рута.

и что стало с этой системой? угадаю с одного раза: снесли вы её нафиг, и только одна home и осталася.

Систему я удалил в виду устаревания ПО, и каталог /home тоже, так как на нем ни чего ценного не хранил, все было на другом разделе.
Безопасность тут была не причем.

Для личного использования, тут безопасность думаю не страдает.

На самом деле есть тут опасность в плане безопасности системы, но она не связанна с правами доступа, она связанна с тем, что юзер может постепенно заполнить свой каталог который находится на том же диске что и home, настолько, что в результате чего опять будет наблюдаться нехватка памяти, а если используется только один раздел диска (корневой) , то в таком случае будут наблюдаться чудеса в поведении системы.

Что мне и нравится в Linux, так это то, что проблему можно решить разными способами.

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

В таком случае, симлинки и bind, в плане безопасности слабое решение по сравнению с использованием файла в качестве жесткого диска.

ormorph написал:

Fat-Zer загрузка системы как проходила нормально?
Просто интересно.

fstab написал:

/store/portage /usr/portage auto bind 0 0

Да, всё вполне нормально.

ormorph написал:

На самом деле есть тут опасность в плане безопасности системы, но она не связанна с правами доступа, она связанна с тем, что юзер может постепенно заполнить свой каталог который находится на том же диске что и home, настолько, что в результате чего опять будет наблюдаться нехватка памяти, а если используется только один раздел диска (корневой) , то в таком случае будут наблюдаться чудеса в поведении системы.

ormorph написал:

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

В таком случае, симлинки и bind, в плане безопасности слабое решение по сравнению с использованием файла в качестве жесткого диска.

это уже совсем страшно.... собственная светлая память страдает ещё сильнее, чем при использовании бинда или симлинков... да и выгоды в безопасности я здесь не вижу по сравнению с тем же биндом

Например каталог /usr/portage можно в полной мере считать данными, почти такими же как сырцы, музыка и прон, а не какими-то важными системными файлами... так что ИМХО вполне допустимо его куда-то переместить.
Так что тут можно использовать любой из 4-х способов описанных здесь.
И ещё по поводу монтирования ФС из файла: думал как раз для дерева портеджей это сделать с целью сжатия... Однако тут линукс до сих пор далеко позади... ничего приличного с прозрачным сжатием пока не существует(поправьте меня)... ещё хотел в рейзер запихнуть, но тут больше вопрос возникает, какого размера ФС сделать... надо подгонять и в общем руки не дошли.

//оффтоп

Fat-Zer написал:

я чего-то не найду, какие переменные за местоположение /usr/portage/distfiles и /usr/portage/packages отвеччают...

emerge --info | grep 'PKGDIR|DISTDIR'
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"

Fat-Zer
Выгода тут в том, что память которая отведена под файл уже забита этим файлом, и ее уже нельзя пользователю заполнить, следовательно файл смонтированный в опредиленный каталог, -память в этом каталоге остается та же (соответствует размеру файла минус то чем забиваешь этот каталог), bind этого не обеспечивает.
Идея в том, что создается файл опредиленного размера

dd if=/dev/zero of=/home/ext3.img count=? bs=1M

параметр count опредиляет количество блоков, размер которых обредиляет параметр bs
Сколько вам этих блоков надо это уже на ваше усмотрение.

далее форматируется данный файл и прописывается в /etc/fstab
команды которыми это проделать вы должны знать.
fs выбирать вам ext3 ext4

все довольно просто.

Если надо подробнее как это проделать, то сейчас я не за компом(мобила), а завтра я могу написать подробнее.

Lupo Alberto извини сначала к тебе обращение написал))

ormorph, это я всё знаю wink , в том что файл заданного размера есть и минус, даже два: место может просто закончится, а с другой стороны будет занят лишний объём на диске. Первый просто решается, ибо увеличить размер образа совсем не сложно, а, например, рейзер и xfs можно увеличивать даже без размонтирования :D .
На счёт размера опять же квотирование спасёт мир... правда на своём десктопе этим влом заниматься smile, а так как ничего сверхважного не на корне не лежит, то проще просто следить за тем, чтобы память не кончилась...

Fat-Zer написал:

ormorph, это я всё знаю wink , в том что файл заданного размера есть и минус, даже два: место может просто закончится, а с другой стороны будет занят лишний объём на диске. Первый просто решается, ибо увеличить размер образа совсем не сложно, а, например, рейзер и xfs можно увеличивать даже без размонтирования :D .
На счёт размера опять же квотирование спасёт мир... правда на своём десктопе этим влом заниматься smile, а так как ничего сверхважного не на корне не лежит, то проще просто следить за тем, чтобы память не кончилась...

Сам знаю, рецепт был для перестраховщиков)

На домашнем компе вся эта перестраховка, это лишнее,
так как сам следишь за тем что бы всего хватало)

Fat-Zer
Посмотрел, действительно по поводу прозрачного сжатия, мало чего хорошего имеется.
Вот нашел fuse-zip можно через layman добавить оверлей zugaina там имеется.

Правда удобным fuse-zip не назовешь, плюсы монтируется обычный zip-архив в качестве fs, хотя это для кого как. Все изменения кешируются, после того как от-монтируешь, начинают добавляться в архив.
Минусы для монтирования используется своя команда, нельзя добавить в /etc/fstab в принципе оно понятно почему это сделано, как раз из за того, что изменения добавляются после от-монтирования.

Так же доступ к при-монтированному каталогу имеет доступ только пользователь, который смонтировал эту fs , например если юзер смонтировал, то рут не сможет просмотреть этот каталог, он будет видеться ему как файл, видно сделано что бы ни кто кроме хозяина не смог от-монтировать.

fuse-zip пробовал... ещё нет поддержки ссылок(ни жёстких ни мягких), нет прав доступа, и возникает геморой с кодировкой... всё это обусловлено скудностью zip-архивов... в общем практически бесполезная вещь, как ФС.

Ещё здесь есть что-то интересное. По заявлениям может монтировать .tar.gz .tar.bz2, но я пока не пробовал...

Ещё есть fusecompress (есть в в каких-то оверлеях). Но она работает по-другому: её натравливаешь на какую-то директорию и она сжимает большие файлы хранящиеся на диске, для сжатия дерева портеджей бесполезна.

Хотелось бы конечно что-нибудь в ядре на подобие reiserfs со сжатием в качестве бонуса... но это пока только мечты...

попробовал archivemount
через овелей ставил

git clone git://gitorious.org/ineluctable-overlay/ineluctable-overlay.git

то же самое что и fuse-zip, ради интереса попробовал скопировать дерево портов, при копировании некоторых файлов выдает ошибку, ну и симлинки не создает :(
если и стоит использовать, так это монтирования архивов.
На fuse-zip у меня хотя бы дерево портов скопировалось, а здесь на некоторых каталогах и файлах выдает ошибку.
Думаю тоже использовать не стоит, больно сырая вещь.

пробовал еще btrfs
http://ru.wikipedia.org/wiki/Btrfs
но что то не ощутил сжатия, du -sh выдает меньший размер( например для дерева портов в 3 раза ) , при этом если создать образ меньше размера каталога дерева портов, то вываливается в ошибку( не хватает места ), df при этом показывает заполнение на 33%. Либо я просто не разобрался как она работает.
Ну и не форматирует образ менее 256М.

На нетбуке давно собираюсь btrfs попробовать... обещают много всяких вкусностей, особенно вкусно в моём случае оптимизация под ssd и прозрачное сжатие... но её разработка застыла полтора года назад... боюсь так и останется проект недоделанным=(
Ещё конечно zfs модульный можно упомянуть, но это уж совсем суровой решение=))

ormorph написал:

симлинки не создает

а если попробовать архив с симлинками и прочими юникс-извращенными-файлами(aka девайсы, пайпы и соккеты) смонтировать? например stage3? хотя вряд ли смонтируется...

Fat-Zer написал:

а если попробовать архив с симлинками и прочими юникс-извращенными-файлами(aka девайсы, пайпы и соккеты) смонтировать? например stage3? хотя вряд ли смонтируется...

Не архив с симлинками монтируется норм, но судя по времени и загрузке процессора, то похоже что просто кешируется куда-то во время монтирования, то-есть похоже на работу обычного архиватора.

У fuse-zip такого не наблюдал.

поэксперементировал c btrfs... странно она себя ведёт как-то...

кароче чего-то определение размера барахлит... наверное сказывается девелоперская версия...
да и файл из нулей не сжался совсем по du, но вывод ва не изменился... сравните со случайным файлом... итого упаковка файлов вроде работает, а сжатие и дыры недопилены...
Часть два(без -o compress):

кароче система сырая и недопиленная....

Незнаю на сколько допилена btrfs, но похоже в качестве образа лучше не использовать(в виде файла)

Использовал версию что в ядре, правда ядро не очень то и новое.
собрал просто модуль:

cd /usr/src/linux
make CONFIG_BTRFS_FS=m M=fs/btrfs/
mkdir /lib/modules/2.6.xx-gentoo/kernel/fs/btrfs
cp fs/btrfs/btrfs.ko /lib/modules/2.6.xx-gentoo/kernel/fs/btrfs
depmod -a

Что размер обманывает, я сразу заметил, хотя не пользовал в качестве раздела, может что изменится. Правда сейчас не очень то хочется этим заниматься smile