Комментарии 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 очень стабилен и содержит кучу весьма древних библиотек. Просто так из последней убунты вытащить нечто и заставить работать под CentOS — не один пот сойдет.
Ну а openjdk вовсе не то же самое, что oracle-jdk. Тут не по одним граблям бегать придется почему стабильное приложение на oracle-jdk собирается и работает, а под openjdk ни в какую. Ну и наоборот.
Ну и так… рекомендации… если ставите несколько вариантов java на машине, то пользуйтесь для переключения alternatives. Не портите жизнь себе и окружающим.
А то что поставили ант распаковкой бинарников из архива, даже без rpm — видимо очень быстро надо и сильно доверяете источнику.
если ставите несколько вариантов java на машине, то пользуйтесь для переключения alternativesспасибо, учту
Обычно 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.
Если вам нужен актуальный 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 по вкусу.
Большое спасибо за совет. Учту.
Про 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
. Не все сборки примут произвольный редактор (через переменную окружения), но в большинстве дистрибутивов это разрешено.
usermod -a -G wheel [username]
Строка " %wheel ALL=(ALL) ALL" в sudoers файле насколько я помню по-умолчанию включена… Если нет то надо ее раскоментить.
Просто добавляешь юзера в эту группу
Строка %wheel по умолчанию закомментирована. Получается всё равно надо редактировать sudoers
Не ссорьтесь, есть ли она, закомментирована или нет — зависит от мейтейнеров конкретного дистрибутива. В ванильной сборке, вероятнее всего, будет закомментирована.
Готовлю CentOS 6.8 к работе