[freebsd]version upgrade
Апдейтинг, как я понимаю, нужно читать всегда.
нужно ли читать /usr/src/UPDATING или можно сразу к делу?Берись за скальпель, мясник!
Берись за скальпель, мясник!
а если серьезно ? нафига тогда такое понятие "релиз" ?
Нужно делать так, как написано в документации или можно сразу к делу?
ты чего то загадками говоришь, не виляй - говори мало, но точно 
Короче и лучше --- не бывает.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
я не говорил "короче", не искажай смысл
s/Короче/Точнее/
---
...Я работаю...
---
...Я работаю...
Если производить upgrade ОС с определенного релиза на следующий, то гарантируется ли корректная сборка ядра и мира старым компилятором ?
да. сначала компилируется новый gcc, потом с использованием этого gcc, компилируется новый мир и ядро
Переформулировка:
Если производить upgrade ОС с определенного релиза на следующий, нужно ли читать /usr/src/UPDATING или можно сразу к делу ?
ну читать-то надо, и еще Makefile не забудь
правильно я понимаю, что при пересборки всего: мира и ядра, при каноническом способе обновления все само корректно компилируется ?
make buildworld --- в /usr/obj будет новый компилятор
make buildekernel KERNKONF=MYKERNEL ---- make знает, что в /usr/obj есть новый компилятор и корректно построит ядро, или не так ?
make buildworld --- в /usr/obj будет новый компилятор
make buildekernel KERNKONF=MYKERNEL ---- make знает, что в /usr/obj есть новый компилятор и корректно построит ядро, или не так ?
почитай лучше /usr/src/Makefile
По идеи да, если ты все делаешь так как написали в Makefile.
кстати как выполняется make installworld ?
каким make нужно выполнять и в какую директорию переходить чтобы был нужный makefile ?
каким make нужно выполнять и в какую директорию переходить чтобы был нужный makefile ?
cd /usr/src
make buildworld && make installworld
make buildworld && make installworld
каким make нужно выполнять и в какую директорию переходить чтобы был нужный makefile ?
да.
cd /usr/src && less Makefile
(читайте внимательно) Лучше читать доку сначала:
http://unix.hackers/docs/FreeBSD/handbook/makeworld.html
и еще
зачем нужно выполнять mergemaster после make installworld ? и какие буковки нажимать при работе mergemaster, "i" или "m" ?
зачем нужно выполнять mergemaster после make installworld ? и какие буковки нажимать при работе mergemaster, "i" или "m" ?
зачем нужно выполнять mergemaster после make installworld ?
добавить новые конфиги. Часто что-то будет сломать после installworld без mergemaster.
и какие буковки нажимать при работе mergemaster, "i" или "m" ?
это сам ты должен знать какие изменения нужны.
это сам ты должен знать какие изменения нужны.
если изменялся только /etc/rc.conf, /etc/passwd плюс еще кое-что ---- то все остальное можно спокойно удалять ?
нет, наоборот. Обычно спокойно удалят rc.conf, passwd, rc.firewall, ... а для всех остальных можно нажать клавишу 'i"
оффтоп: freebsd 6.0 кто-нить видел уже?
его с cvs с тегом HEAD брать ?
Наверное... Я не рискну свою систему так терзать 
На самом бсдшном сайте инфу о 6.0 можно найти только косвенную.
На самом бсдшном сайте инфу о 6.0 можно найти только косвенную.
Инфа, как я понимаю, на freebsd-
подожди, ведь mergemaster -p делает preserve копию старого или нового /etc ?
как я понимаю:
mergemaster -p --- оставляет какую-то информацию про старый /etc в /var/tmp
make installworld ---- затирает старый /etc на новый
mergemaster ----- предлагает скорректировать новый /etc по информации в /var/tmp
или я не прав ?
как я понимаю:
mergemaster -p --- оставляет какую-то информацию про старый /etc в /var/tmp
make installworld ---- затирает старый /etc на новый
mergemaster ----- предлагает скорректировать новый /etc по информации в /var/tmp
или я не прав ?
> оффтоп: freebsd 6.0 кто-нить видел уже?
Так зовётся CURRENT с момента отщепления RELENG_5. У меня стоит на десктопе, на ноутбуке и на тестбоксе.
Так зовётся CURRENT с момента отщепления RELENG_5. У меня стоит на десктопе, на ноутбуке и на тестбоксе.
если изменялся только /etc/rc.conf, /etc/passwd плюс еще кое-что ---- то все остальное можно спокойно удалять ?Грубое правило звучит так: если ты не знаешь, что это за файл, то нужно инсталлировать новую версию.
во бля
оказывается все наоборот
а зачем тогда нужно два mergemaster, до и после ?
оказывается все наоборот
а зачем тогда нужно два mergemaster, до и после ?
> mergemaster -p --- оставляет какую-то информацию про старый /etc в /var/tmp
> make installworld ---- затирает старый /etc на новый
Это не врите! installworld - автоматическая процедура, а /etc опасно подвергать автоматическим изменениям.
> mergemaster ----- предлагает скорректировать новый /etc по информации в /var/tmp
по информации в /usr/src/etc
-p Pre-buildworld mode. Compares only files known to be essen-С тебя $10.
tial to the success of {build|install}world, including
/etc/make.conf.
> make installworld ---- затирает старый /etc на новый
Это не врите! installworld - автоматическая процедура, а /etc опасно подвергать автоматическим изменениям.
> mergemaster ----- предлагает скорректировать новый /etc по информации в /var/tmp
по информации в /usr/src/etc
все бля с меня 10 $
с первой пенсии вышлю
с первой пенсии вышлю
Compares only files known to be essen-
tial to the success of {build|install}world, including
/etc/make.conf.
а что происходит с остальными ?
> а зачем тогда нужно два mergemaster, до и после ?
Такое бывает очень редко. mergemaster до installworld нужен только в тех случаях, когда installworld не пройдёт со старым /etc.
Что бы было понятнее, пример: если появляется новый системный пользователь, например smmsp и mailnull, то они должны существовать в /etc/passwd до того, как install будет создавать файлы принадлежащие этим пользователям.
Такое бывает очень редко. mergemaster до installworld нужен только в тех случаях, когда installworld не пройдёт со старым /etc.
Что бы было понятнее, пример: если появляется новый системный пользователь, например smmsp и mailnull, то они должны существовать в /etc/passwd до того, как install будет создавать файлы принадлежащие этим пользователям.
> а что происходит с остальными ?
Ничего. Они не сравниваются, значит игнорируются.
Ничего. Они не сравниваются, значит игнорируются.
а как обходились до 4.6 ?
т.е. в /etc остается мусор ?
Без чего обходились?
> т.е. в /etc остается мусор ?
Не мусор, а старые файлы.
Ты несешь пургу, поэтому объясняю что такое mergemaster. Это программа, которая визуально показывает разницу между /usr/src/etc и /etc. Обычно в /usr/src/etc находятся конфигурационные файлы и скрипты от версии FreeBSD, которую ты поставил. В /etc находятся те файлы с которыми ты работал до сегодняшнего момента. Они имеют право отличаться от тех, которые получаются при инсталляции с нуля. Ты мог добавить пользователей, подхачить стартовые скрипты, всё что угодно. Поэтому их нельзя тупо заменить на файлы из /usr/src/etc. Но оставить их не тронутыми тоже не хорошо, а иногда и очень плохо. Потому что они могут быть не совместимы с новой версией FreeBSD, например:
1) У OpenSSH изменились опции в sshd_config, ssh_config.
2) У какой-то из множества утилит используемых при старте или при daily checks появились новые флаги.
3) У sendmail изменилась версия и как следствие sendmail.cf
4) Появились новые каталоги в файловой системе и это не отражено в /etc/mtree.
Когда mergemaster находит разные файлы, то он отображает тебе разницу между ними. Если ты стопудово уверен, что этот файл ты никогда не трогал, то можешь смело инсталлировать новую версию. В обратном случае у тебя есть возможность оставить старую версию или в ручном режиме смержить старую и новую.
mergemaster -p анализирует только файлы необходимые для выполнения installworld. Без -p - все файлы.
Не мусор, а старые файлы.
Ты несешь пургу, поэтому объясняю что такое mergemaster. Это программа, которая визуально показывает разницу между /usr/src/etc и /etc. Обычно в /usr/src/etc находятся конфигурационные файлы и скрипты от версии FreeBSD, которую ты поставил. В /etc находятся те файлы с которыми ты работал до сегодняшнего момента. Они имеют право отличаться от тех, которые получаются при инсталляции с нуля. Ты мог добавить пользователей, подхачить стартовые скрипты, всё что угодно. Поэтому их нельзя тупо заменить на файлы из /usr/src/etc. Но оставить их не тронутыми тоже не хорошо, а иногда и очень плохо. Потому что они могут быть не совместимы с новой версией FreeBSD, например:
1) У OpenSSH изменились опции в sshd_config, ssh_config.
2) У какой-то из множества утилит используемых при старте или при daily checks появились новые флаги.
3) У sendmail изменилась версия и как следствие sendmail.cf
4) Появились новые каталоги в файловой системе и это не отражено в /etc/mtree.
Когда mergemaster находит разные файлы, то он отображает тебе разницу между ними. Если ты стопудово уверен, что этот файл ты никогда не трогал, то можешь смело инсталлировать новую версию. В обратном случае у тебя есть возможность оставить старую версию или в ручном режиме смержить старую и новую.
mergemaster -p анализирует только файлы необходимые для выполнения installworld. Без -p - все файлы.
без mergemaster-а
> Если ты стопудово уверен, что этот файл ты никогда не трогал, то можешь смело инсталлировать новую версию.
А разве оно само не может это понять?
А разве оно само не может это понять?
А разве оно само не может это понять?
вроде как для этого нужно "mergemaster -a -p"
> А разве оно само не может это понять?
Для того, что бы это понять нужен CVS репозиторий.
Для того, что бы это понять нужен CVS репозиторий.
> без mergemaster-а
Без него было плохо.
Без него было плохо.
> Для того, что бы это понять нужен CVS репозиторий.
Нужны всего лишь дистрибутивные варианты конфига, старый и новый.
Если старой версии нет - то это не merging, а что-то ещё.
Нужны всего лишь дистрибутивные варианты конфига, старый и новый.
Если старой версии нет - то это не merging, а что-то ещё.
> > Для того, что бы это понять нужен CVS репозиторий.
> Нужны всего лишь дистрибутивные варианты конфига, старый и новый.
Кроме дистрибутивных еще есть и версии между дистрибутивами. Число исторических дистрибутивов может быть очень большим. Таким образом нужен репозиторий.
> Если старой версии нет - то это не merging, а что-то ещё.
Есть текущая версия и новая. Нужно их слить вместе. Это называется merge, можешь проверить в словаре.
> Нужны всего лишь дистрибутивные варианты конфига, старый и новый.
Кроме дистрибутивных еще есть и версии между дистрибутивами. Число исторических дистрибутивов может быть очень большим. Таким образом нужен репозиторий.
> Если старой версии нет - то это не merging, а что-то ещё.
Есть текущая версия и новая. Нужно их слить вместе. Это называется merge, можешь проверить в словаре.
> Кроме дистрибутивных еще есть и версии между дистрибутивами.
Интересуют только две версии: которая была до апгрейда, и которая стала после.
Поэтому целиком репозиторий не нужен, а нужно только лишь не про№бать то, что лежало в /usr/src/etc до апгрейда.
И когда я запускал mergemaster (один раз у меня сложилось впечатление, что он всё делал правильно, может я ошибся.
> Есть текущая версия и новая. Нужно их слить вместе. Это называется merge, можешь проверить в словаре.
Обычно сливают не версии файлов, а изменения.
Одно изменение, которое сделал админ, и другое, которое сделали разработчики.
Типа вот:
Интересуют только две версии: которая была до апгрейда, и которая стала после.
Поэтому целиком репозиторий не нужен, а нужно только лишь не про№бать то, что лежало в /usr/src/etc до апгрейда.
И когда я запускал mergemaster (один раз у меня сложилось впечатление, что он всё делал правильно, может я ошибся.
> Есть текущая версия и новая. Нужно их слить вместе. Это называется merge, можешь проверить в словаре.
Обычно сливают не версии файлов, а изменения.
Одно изменение, которое сделал админ, и другое, которое сделали разработчики.
Типа вот:
MERGE(1) MERGE(1)
NAME
merge - three-way file merge
SYNOPSIS
merge [ options ] file1 file2 file3
DESCRIPTION
merge incorporates all changes that lead from file2 to
file3 into file1. The result ordinarily goes into file1.
merge is useful for combining separate changes to an orig╜
inal. Suppose file2 is the original, and both file1 and
file3 are modifications of file2. Then merge combines
both changes.
> Интересуют только две версии: которая была до апгрейда, и которая стала после.
До апгрейда могла быть любая.
> Поэтому целиком репозиторий не нужен, а нужно только лишь не про№бать то, что лежало в /usr/src/etc до апгрейда.
Там могло лежать что угодно, не обязательно то же, что в /etc.
> И когда я запускал mergemaster (один раз у меня сложилось впечатление, что он всё делал правильно, может я ошибся.
Всё сделал правильно, но только не таким образом, как ты думаешь.
До апгрейда могла быть любая.
> Поэтому целиком репозиторий не нужен, а нужно только лишь не про№бать то, что лежало в /usr/src/etc до апгрейда.
Там могло лежать что угодно, не обязательно то же, что в /etc.
> И когда я запускал mergemaster (один раз у меня сложилось впечатление, что он всё делал правильно, может я ошибся.
Всё сделал правильно, но только не таким образом, как ты думаешь.
> До апгрейда могла быть любая.
Да, но дистрибутивные конфиги у неё были обязательно.
Вот их и стоило бы сохранить в надёжном месте, до апгрейда.
> Всё сделал правильно, но только не таким образом, как ты думаешь.
Значит, неправильно.
debian тоже так делает, но он хоть сам определяет, когда админ не редактировал конфиг (по контрольной сумме, наверное).
Да, но дистрибутивные конфиги у неё были обязательно.
Вот их и стоило бы сохранить в надёжном месте, до апгрейда.
> Всё сделал правильно, но только не таким образом, как ты думаешь.
Значит, неправильно.
debian тоже так делает, но он хоть сам определяет, когда админ не редактировал конфиг (по контрольной сумме, наверное).
а ты делал backup /etc ?
я вот сделал, мне помогло
я вот сделал, мне помогло
как всё сложно
при обновлении нескольких серверов на каждом вручную делать merge?
ну тогда делись секретом как автоматизировать.
как раз это меня интересует
Глеб тут хвалил программу dd
пиздец
а папа не знаком с генту ?
так бы рассказал бы как в генту решили данную проблему
так бы рассказал бы как в генту решили данную проблему
её там решили?
её там решили?
я полагаю что решили, т.к. там все пересобирается "emerge <что-то там>"
debian тоже так делает, но он хоть сам определяет, когда админ не редактировал конфиг (по контрольной сумме, наверное).Еще раз: для этого нужен репозиторий. Потому что текущая версия может быть не из предыдущего дистрибутива, а из любого другого, сколь угодно старого.
> при обновлении нескольких серверов на каждом вручную делать merge?
Да. При правильной организации на это уходит около пары минут.
Да. При правильной организации на это уходит около пары минут.
> Потому что текущая версия может быть не из предыдущего дистрибутива, а из любого другого, сколь угодно старого.
Какая разница, насколько он старый, если в момент его установки можно сохранить дистрибутивные конфиги в надёжном месте.
И пусть лежат до следующего апгрейда.
Кажется, несколькими постами выше я именно так и написал.
Какая разница, насколько он старый, если в момент его установки можно сохранить дистрибутивные конфиги в надёжном месте.
И пусть лежат до следующего апгрейда.
Кажется, несколькими постами выше я именно так и написал.
что значит "правильная организация"?
> что значит "правильная организация"?
Это значит, что когда вносишь изменения в /etc, то думаешь.
Это значит, что когда вносишь изменения в /etc, то думаешь.
Какая разница, насколько он старый, если в момент его установки можно сохранить дистрибутивные конфиги в надёжном месте.Только сейчас объяснил понятно. Будет место занимать однако. Так где нибудь делается?
И пусть лежат до следующего апгрейда.
Кажется, несколькими постами выше я именно так и написал.
> Так где нибудь делается?
До сегодняшнего дня я думал, что во FreeBSD
> Будет место занимать однако.
Да ну, это ж конфиги.
До сегодняшнего дня я думал, что во FreeBSD
> Будет место занимать однако.
Да ну, это ж конфиги.
По-хорошему, всё равно полезно /etc/* в VCS загнать.
По крайней мере, если кто напортачил, хоть откатить можно будет.
А ещё хорошо было бы, если б это шло сразу по умолчанию.
---
...Я работаю...
По крайней мере, если кто напортачил, хоть откатить можно будет.
А ещё хорошо было бы, если б это шло сразу по умолчанию.
---
...Я работаю...
# du -sh /etc
2,9M /etc
Свежеустановленное дерево портов занимает раз в десять больше.
---
...Я работаю антинаучным аферистом...
По-хорошему, всё равно полезно /etc/* в VCS загнать.Так и делается там, где работает много людей + сложные конфигурации.
По крайней мере, если кто напортачил, хоть откатить можно будет.
> А ещё хорошо было бы, если б это шло сразу по умолчанию.
А это уже спорный вопрос.
Далеко не всякая BSD есть MonoWall.
Кроме того, в BSD и так есть очень много мест,
где можно было бы сократить расходование памяти.
Но ведь не режут же?
А тут всего 3 мегабайта, из которых не особо много-то меняется.
---
...Я работаю антинаучным аферистом...
Кроме того, в BSD и так есть очень много мест,
где можно было бы сократить расходование памяти.
Но ведь не режут же?
А тут всего 3 мегабайта, из которых не особо много-то меняется.
---
...Я работаю антинаучным аферистом...
попробуй немного формализовать своё высказывание
совет "думай" может дать любой
совет "думай" может дать любой
Курсы системных администраторов сегодня платные.
хорошо
10$, если ты дашь действительно хороший ответ
как по человечески автоматизировать обновление freebsd?
10$, если ты дашь действительно хороший ответ
как по человечески автоматизировать обновление freebsd?
я тоже хочу знать секреты системных гуру-администраторов.
Общественность требует
Общественность требует
> я тоже хочу знать секреты системных гуру-администраторов.
Понимаешь, мальчику у опять хочется пофлеймить, а у меня сегодня нет такого настроения. Я готов ответить на конкретные вопросы про mergemaster, но сегодня у меня нет времени вступать в обсуждение "как по-нормальному обновить FreeBSD в автоматическом режиме". Как я уже сказал, у меня обычно на mergemaster уходит меньше двух минут, и я не считаю это много.
Задавай конкретные вопросы и на них я отвечу.
Понимаешь, мальчику у опять хочется пофлеймить, а у меня сегодня нет такого настроения. Я готов ответить на конкретные вопросы про mergemaster, но сегодня у меня нет времени вступать в обсуждение "как по-нормальному обновить FreeBSD в автоматическом режиме". Как я уже сказал, у меня обычно на mergemaster уходит меньше двух минут, и я не считаю это много.
Задавай конкретные вопросы и на них я отвечу.
Оставить комментарий
krishtaf
Возник вопрос:Если производить upgrade ОС с определенного релиза на следующий, то гарантируется ли корректная сборка ядра и мира старым компилятором ?
Переформулировка:
Если производить upgrade ОС с определенного релиза на следующий, нужно ли читать /usr/src/UPDATING или можно сразу к делу ?