Тогда сравнение неверно

Почему неверно?

это как systemd, только httpd, неужели непонятно ^_^

Веб-сервера Apache не существует, Apache - это фонд СПО. Их веб-сервер называется именно [Apache] httpd.

Чуть сложнее - это могло бы привести к конфликту. Нужен арбитраж.

Тут очень простой арбитраж - самодурство тирана

Почему неверно?

Потому что нет такой плоскости сравнения apache vs nginx, кроме очень узких случаев

Тут очень простой арбитраж - самодурство тирана

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

Потому что нет такой плоскости сравнения apache vs nginx, кроме очень узких случаев

Собственно, в случае с DNS примерно так же.

Собственно, в случае с DNS примерно так же.

Не совсем. Это ортогональные вещи. Аналогии некорректны

Никто не сравнивает HTTP и DNS.

Что не отменяет того факта, что и httpd, и named - огромные, неповоротливые монстры, а ldns и nginx - маленькие и быстрые.

Ну и как следствие: в случае выбора DNS-сервера я выберу LDNS, если только мне не понадобится специфическая функциональность named; и в случае выбора веб-сервера выберу nginx, если только мне не понадобится специфическая функциональность httpd.

Смотри выше, про вызов bind(). Я бы вообще не держал на одной машине рекурсор и авторитетный сервер. Но если уж надо - jail же, и разные адреса.

А что мешает просто сделать форвард на рекурсоре? Ну или пакетным фильтром смотреть на флаг рекурсии и форвардить на соответствующий сервис

Ничто не мешает, я такого не утверждал. ?

Более того, когда мне было удобно - я forward на рекурсоре и делал. Однако, вариант с пакетным фильтром считаю херовым, ибо тормоз (допустим, у нас 100k rps - лезть в каждый пакет будет немного извращением). Но всё это нисколько не отменяет того, что если тебе нужно и авторитетный, и рекурсор на одной машине - адреса нужно разные юзать.

Всем привет

Ребят подскажите , как сделать pkg upgrade грамотно ? а то вот например есть gitlab 9.2

pkg upgrade<ENTER>y<ENTER> - обычно так.

обновились ryby gem и тп, делаю pkg upgrade собственно, обновления ставятся нормально, но gitlab тот же потом ругается на отсутсиве gem файлов, ведь он собран был с одними версиями ПО, а в системе стояли другие.

у меня свой репозитории пакетов. И вот например обновиться ruby, Poudire это учитывает и пересобирает что от Ruby зависило ( тот же gitlab ), потом делаю со своего репозитория pkg upgrade, обновится только Ruby, пересобранный Gitlab не обновиться так как имеет ту же версию что и стоит уже. А собраны с разными версиями зависимостей.

С чего ты взял, что не обновится?

Потому что уже 100500 раз это проверил

У меня собран Exim 4.89 с поддержкой MySQL, выходит новая версия mysql-client и poudire пересоберет и Exim и все что от mysql-client Зависило, но при pkg upgrade обновиться только mysql-client

Странно, а у меня в таких случаях pkg пишет 'reinstalling because dependency version changed' или вроде того.

когда то пишет, когда то нет.

в том и дело

вот у себя только что gitlab угрохал в очередной раз

У меня собран Exim 4.89 с поддержкой MySQL, выходит новая версия mysql-client и poudire пересоберет и Exim и все что от mysql-client Зависило, но при pkg upgrade обновиться только mysql-client

Значит, ABI не изменилось.

когда то пишет, когда то нет.

Так пиши багрепорт.

pkg обязан все эти ситуации разруливать, именно для этого и писали.

bundle install выручит и gitlab заведется, но это уже костыль, хочу чтобы ПО было из пакетов и портов.

а pkg умеет реинсталл ПО с зависимостями вместе ?

Понятия не имею - у меня таких проблем никогда не было. Глянь man же. Автоматически - точно умеет.

как удалить www/gitlab с зависимостями вместе ?

man pkg-remove

Но сразу говорю - вопрос некорректен и поэтому на него не может быть корректного ответа.

Перед апдейтами, лучше заглядывать в /usr/ports/UPDATING он не всегда, но в большинстве случаев решает всё что может пойти не так, в остальных случаях в принципе всё должно идти так и надо просто следовать тому что выдаётся консолькой :)

poudriere пересобирает всё в общем с запасом, и да не всё после этого обновляется по pkg, так как в принципе и не должно, там много обновляется из-за билд депендс и прочего

просто надоело уже постоянно доставлять нехватающих Gem после pkg upgrade

ну так всякие перлы/питоны.руби лучше управлять через их собственные менеджеры, порты к сожалению, крайне паршиво для них приспособлены

как впрочем и всякие линуксовые пакеты

а их собственные менджеры еще хуже, ага

ибо ёбаные хипсторы

ну так всякие перлы/питоны.руби лучше управлять через их собственные менеджеры, порты к сожалению, крайне паршиво для них приспособлены

Почему же паршиво?

если тебе не обновляться, подойдут и порты

пох portupgrade -fR gitlab сделаю может так прокатит

а вот мешать порты и пакеты, можно только если совсем совсем уверен в своих силах

Господа, ну это же бред какой-то. Если после апдейта завимостей Gitlab он ломается - значит, изменилось ABI. А если оно изменилось - значит, Gitlab должен бы пересобраться, а pkg должен был его переустановить.

Если этого не происходит - значит, в Gitlab указаны некорректные зависимости. А если так - должен быть написан PR.

Да ты шо...

По делу есть, что сказать?

ой, так вы с этим хипсторским говнецом трахаетесь? там такое норма вещей :D отсюда и curl | bash

Не имеет абсолютно никакого значеня, с каким портом пердолиться. Кривые depends могут быть, где угодно.

тут не порт, тут сам продукт такое

В контексте решения задачи с некорректными зависимостями это не имеет значения.

Ниразу не было проблем обновлением гитлаба

хоть на Linux сваливай.... Надоело все это уже за десяток лет испольщования FreeBSD

Всё всегла ставится

Собственно мануал

http://gitlab.toco-domains.de/FreeBSD/GitLab-docu/blob/master/update/9.2-to-9.3-freebsd.md

Ибо докер

фряха в докере ?

Обновление в одну команду

фряха в докере ?

Жжешь

В две точнее

я мало читал про докер, поставить поставил, но нифига не разобрался, да и времени на это пока что нет.

И не стоит. Придется поменять религию

http://gitlab.toco-domains.de/FreeBSD/GitLab-docu/blob/master/update/9.2-to-9.3-freebsd.md

Ну и? В чём проблема? Стопнул демона, обновил пакет, смигрировал конфиг, запустил демон.

ERROR: S client not available

затык на обновлении базы

пишет например сразу peek-mysql2 отстутвует и так далее

решается bundle install

но через bundle install Не собирается grpc

https://gitlab.com/gitlab-org/gitaly/issues/154

пишет например сразу peek-mysql2 отстутвует и так далее

"Я что-то делаю, у меня что-то не получается, помогите чем-нибудь."

ну я ж написал что решается установкой Gemов через bundle install, а какого хрена с портов они не подцепляются не понимаю.

make -C /path/to/gitlab/port all-depends-list

может ccache конечно как то виноват что код берет из кеша, вообще стоит его использовать ? или отказаться вовсе

а то было пару раз что кеш чистишть пересобираешь все ок, иначе что то точно не соберется

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

Тебе что нужно - поныть, как всё плохо или понять, в чём проблема?

а ты всё флудиш и флудиш :)

может ccache конечно как то виноват что код берет из кеша, вообще стоит его использовать ? или отказаться вовсе

А смысл его юзать если не пересобираеш по сто раз?

Во-первых, флудишь. Во-вторых, https://ru.m.wikipedia.org/wiki/%D0%A4%D0%BB%D1%83%D0%B4. Мои сообщения под определение флуда не попадают. В-третьих, если бы он делал то, что я говорю - проблема бы уже была решена (либо завершением обновления, либо написанием PR).

мы рады за твоё умение пользоваться википедией но нам похуй

о, еще кто-то просвещением молодых по сетевой культуре занялся

о пердуны песочком дорожку подсыпать припёрлись

мы рады за твоё умение пользоваться википедией но нам похуй

А вот это уже ближе к флуду, ибо вообще никак не относится ни к тематике группы, ни к проблеме @deathstar_name с обновлением.

Пока что удалил GitLab с завимостями , пробую ставить с нуля

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

а где же самое главное "работа такая" :?

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

У меня нет никаких сложностей с портами. Оно либо: 1. Работает; 2. Не работает, я пишу PR, и оно снова работает.

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

Ага и не помолился ктулху

Не обязательно. Главное - руки.

в ПО косяк походу

root@deathstar:/usr/local/www/gitlab # su -l git -c "cd /usr/local/www/gitlab && rake gitlab:setup RAILS_ENV=production" "man firewall" will give advice for building a FreeBSD firewall — David Scheidt <dscheidt@tumbolia.com> DEPRECATION WARNING: alias_method_chain is deprecated. Please, use Module#prepend instead. From module, you can access the original method using super. (called from <top (required)> at /usr/local/www/gitlab/config/application.rb:5) DEPRECATION WARNING: config.serve_static_files is deprecated and will be removed in Rails 5.1. Please use config.public_file_server.enabled = false instead. (called from block in <top (required)> at /usr/local/www/gitlab/config/environments/production.rb:12) rake aborted! TypeError: superclass mismatch for class LockingType /usr/local/www/gitlab/config/initializers/active_record_locking.rb:68:in `<module:Locking>' /usr/local/www/gitlab/config/initializers/active_record_locking.rb:7:in `<module:ActiveRecord>' /usr/local/www/gitlab/config/initializers/active_record_locking.rb:6:in `<top (required)>' /usr/local/www/gitlab/config/environment.rb:5:in `<top (required)>' Tasks: TOP => gitlab:setup => environment (See full trace by running task with —trace)

С чего ты взял, что не обновится?

У перла и пыха ровно та же беда

Неправда. С Perl таких проблем нет (мы же в poudriere собираем). С похапэ - давно не ставил, не буду утверждать.