Как стать автором
Обновить

Комментарии 21

[root@localhost lamp]# chmod +w /etc/sudoers
[root@localhost lamp]# vi /etc/sudoers

Вас не били линейкой? А надо было. Для редактирования sudoers есть visudo, проставить env var EDITOR по вкусу.

И для установки java аж пришлось гуглить и читать туториал. Лучше бы yum(8) посмотрели, узнали бы про yum search, набрали yum search openjdk и потом поставили нужную версию через yum install java-1.8.0-openjdk-devel.


Если вам нужен актуальный ant, то зачем ставить его из archive.apache.org? Почему не посмотреть на официальной странице Apache Ant и не взять актуальную версию?

Скорее всего надо было срочно поставить какой-то проект и опробовать под CentOS 6.8.
Обычно CentOS очень стабилен и содержит кучу весьма древних библиотек. Просто так из последней убунты вытащить нечто и заставить работать под CentOS — не один пот сойдет.
Ну а openjdk вовсе не то же самое, что oracle-jdk. Тут не по одним граблям бегать придется почему стабильное приложение на oracle-jdk собирается и работает, а под openjdk ни в какую. Ну и наоборот.
Ну и так… рекомендации… если ставите несколько вариантов java на машине, то пользуйтесь для переключения alternatives. Не портите жизнь себе и окружающим.
А то что поставили ант распаковкой бинарников из архива, даже без rpm — видимо очень быстро надо и сильно доверяете источнику.
если ставите несколько вариантов java на машине, то пользуйтесь для переключения alternatives
спасибо, учту
Вообще ant пофиг на версию jdk. Ну, почти — наверное можно найти что-то, что будет работать не так, но придется очень сильно постараться.
Обычно CentOS очень стабилен и содержит кучу весьма древних библиотек. Просто так из последней убунты вытащить нечто и заставить работать под CentOS — не один пот сойдет.

Потому что надо тащить не из ubuntu или debian, а из fedora. rpmbuild позволит без проблем пересобрать нужное. Иначе получается жалоба на то, что гланды через жопу очень долго извлекаются.


Ну а openjdk вовсе не то же самое, что oracle-jdk. Тут не по одним граблям бегать придется почему стабильное приложение на oracle-jdk собирается и работает, а под openjdk ни в какую. Ну и наоборот.

Примеры для серверных приложений будут? Отличия рендеринга шрифтов, мелочёвка в swing/awt и javafx нерелевантны. Замечу, что и oracle jdk 8, и openjdk 8 проходят TCK. Проблемы, скорее, возникнут при переходе на IBM J9, Excelsior JET или Azul, когда выяснится, что вы (или ваши зависимости) неудачно влезли в sun.misc или около того.


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

И то, и то — вопрос доверия. В одном случае вы доверяете оригинальному вендору (ASF) и проверяете хэшсумму + pgp/gpg подпись; в другом — доверяете вендору ОС (RedHat/CentOS Project) и проверяете те же хэшсумму + pgp/gpg подпись (за вас это делает rpm, но принципиального отличия нет).

Все верно. Есть разработчики. Есть борьба за актуальные библиотеки.
Есть системщики. Есть собранный давным давно софт. Есть требования этого софта. Бездумная подмена библиотек в 90% случаев приводит к потере работоспособности.
Есть производство. Им важно, чтобы работало. Работало так как описано производителем софта.
Примеры? Общедоступных наверное уже и не осталось. В моей практике это CGG Geovecteur который за последние лет 15 перешагнул через CGG Geocluster, миновал CGG Octopus и достиг CGG Geovation.
Большая часть старых приложений усиленно выгоняется самим производителем с поддержки, так как не осталось уже дистрибутивов с поддержкой openmotif20, openmotif21, openmotif22. Слабое подобие lesstif совместимо только по сырцам. jre 1.6 уже явно везде выгоняется, но до сих пор используется.
Если кто в теме, то у меня сейчас сайт работает на CentOS 6.8. На CentOS 7 пока не перебирался, так как версия ядра уже не та. А когда знакомился с Geovecteur, то он вообще работал на RedHat 7.3 в 2004 году. Лично знаю разработчиков, которые писали для него модули в 1996 под RedHat 6.
А сколько криков вокруг Microsoft .NET сейчас. Сколько борьбы с уязвимостями без которых даже родной Microsoft WSUS перестает работать.
В общем, главное четко видеть для кого и что мы делаем. Если это начинает сильно зависеть от версий, то это плохо. Если это перестает работать при смене минорных версий. Это плохо.…

И что вы хотели сказать этой простынёй? Что проприетарный софт может требовать странного замороженного окружения, т. к. специально не поддерживается? Это естественно и является вполне обычной ситуацией.


Если кто в теме, то у меня сейчас сайт работает на CentOS 6.8. На CentOS 7 пока не перебирался, так как версия ядра уже не та.

У вас сайт/веб-сервер зависит от версии ядра? Зачем вы делали/использовали столь непереносимый подход? Большая часть софта прекрасно работает на новых ядрах не замечая разницы между 2.6.32 и 4.10.9.

SITE, только не WEB.
SITE не только WEB.
Если вам нужен актуальный ant, то зачем ставить его из archive.apache.org

В том и фокус, что актуальный в данной ситуации был не нужен. Устроил бы любой 1.8.*, а уж 1.9.* с головой. Тем не менее за совет — спасибо.
Лучше бы yum(8) посмотрели, узнали бы про yum search, набрали yum search openjdk и потом поставили нужную версию через yum install java-1.8.0-openjdk-devel

Спасибо, я в курсе про команду search, смотрел (только не стал писать об этом). Просто после размышления выбрал ставить именно oracle-jdk так как он не совсем идентичен open-jdk, как верно отметил ниже один комментатор.
Для редактирования sudoers есть visudo, проставить env var EDITOR по вкусу.

Большое спасибо за совет. Учту.
Спасибо за советы по поводу visudo и open-jdk. Учел их, исправив статью (само собой, повторив в реале).
Если совсем 'quick makeshift' подход практиковать при редактировании /etc/sudoers, то, chmod +w — вовсе не обязательно, а достаточно в самом vi ввести по завершению редактирования :wq!
Про ant также верно в комментариях написали. Из archive — как-то не совсем верно.
Наконец, про git. Он у Вас будет достаточно старой версии, в то время, как можно поставить, дополнительно установив neon из rpm правда, версию 1.7.12.
при редактировании /etc/sudoers, то, chmod +w — вовсе не обязательно, а достаточно в самом vi ввести по завершению редактирования :wq!

Спасибо. Впрочем я заметил (спасибо grossws) что команда visudo решает эту проблему — достаточно :wq
Из archive — как-то не совсем верно

Согласен, попробую другие варианты.
про git… версию 1.7.12

1.7.1 меня устроил на 146%
Спасибо. Впрочем я заметил (спасибо grossws) что команда visudo решает эту проблему — достаточно :wq

visudo использует тот редактор, который указан у вас в переменной EDITOR, как я уже писал выше. Т. е. EDITOR=nano visudo и вам не нужно даже знать про :wq. Не все сборки примут произвольный редактор (через переменную окружения), но в большинстве дистрибутивов это разрешено.

EDITOR=nano visudo и вам не нужно даже знать про :wq

Да, понял. Впрочем, в свежеустановленном CentOS 6 nano нет, а vi и команды типа :wq меня не смущают.
Ещё раз спасибо, почерпнул много полезного из ваших комментариев. Как только карма станет приемлемой — отредактирую свою заметку.
Для доступа к sudo существует группа wheel. Просто добавляешь юзера в эту группу:
usermod -a -G wheel [username]


Строка " %wheel ALL=(ALL) ALL" в sudoers файле насколько я помню по-умолчанию включена… Если нет то надо ее раскоментить.
Просто добавляешь юзера в эту группу

Строка %wheel по умолчанию закомментирована. Получается всё равно надо редактировать sudoers

Не ссорьтесь, есть ли она, закомментирована или нет — зависит от мейтейнеров конкретного дистрибутива. В ванильной сборке, вероятнее всего, будет закомментирована.

Именно так. Специально проверил на своём ноуте:
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.