Блог о технологиях, технократии и методиках борьбы с граблями
Есть пара небольших офисов на поддержке, в которых появляюсь только забрать денег раз месяц, за свое наличие и иногда в межсезонье, чтобы они не забывали как я выгляжу, да все ли у них в порядке. Но пока я в stand by в городе- у них все прекрасно и замечательно, иногда заезжаю раз в два месяца за теньге, максимум какие то проблемы могут возникнуть с почтарем или фтп сервисами, но все они решаются удаленно и оперативно.
(more…)
Иногда приключается ситуация, что надо поднять сервак и передать его в руки чужих умельцев, а вы на нем например тестили закрытие трафа в сопряженные сетки, или не хотите палить процедуру настройки сервера.
Для этого надо обнулить историю шелла, или по крайней мере выкинуть из нее какие то фрагменты. Делается это крайне просто, ибо она хранится в файле .bash_history, который находится в домашней директории пользователя, и в случае всяких настроек- root. Естественно что там она хранится в случае использования bash, а не /sbin/nologin
Так что вариантов два, либо обнулить этот файл
# cat /dev/null > ~/.bash_history
либо открыть его на редактирование и постирать ненужные строки ручками.
В обоих случаях надо будет перелогиниться, чтобы shell очистился, так как данные из него подгружаются при загрузке профайла.
Приключилась тут ситуация, что на одной машине под Vista, скайп начал падать с ошибкой (0×0000005). То есть все вроде работает, а skype прямо на загрузке приложения вываливается с указанным кодом.
Решил было для начала, что глючит Vista и накатил на неё Windows 7, но ошибка осталась, как при первоначальной установке, так и после установки имевшихся патчей. Пришлось гуглить, тем более что в инетах полно советов о том как это лечится, но мне не смог помочь ни один.
У человека, при попытке подключиться к VPN сообществу, через клиента OpenVPN, вылетела ошибка сертификата
error:0906D06C:PEM routines:PEM_read_bio:no start line:
error:140AD009:SSL routines:SSL_CTX_use_certificate_file:PEM lib
Ошибка говорит о том, что с сертификатом какие то траблы, для чего ищем файлик C:\Program Files\OpenVPN\config\Ваше_имя.crt проверяем его размер и если он отличен от нуля, то открываем его в текстовом редакторе и проверяем наличие текста, содержащего мусорный на первый взгляд набор символов, по окончании которого находятся строки:
—–BEGIN CERTIFICATE—–
бла-бла кодированные данные
—–END CERTIFICATE—–
Теоретически если его размер отличен от нуля и данные строки присутствуют, то это проблема с путем до файла сертификата, поэтому проверяем в настройках конфига C:\Program Files\OpenVPN\config\openvpn.ovpn поле
cert Ваше_имя.crt
Если все вроде правильно, а связь тем не менее не устанавливается, то скачиваем сертификаты снова с VPN сервера, ну либо пересоздаем заново. Но как мне кажется все должно ограничиться первыми двумя пунктами.
Подходил к концу 10ти часовой аврал проброса портов на внутренний сервак, в течении которого я обточил сервак, пропатчил его и перешел к самому тривиальному- настройке NAT’а на безусловный редирект в DMZ. Надо заметить, что все это производилось на шлюзе под FreeBSD 8.2 на которой столовалась внутренняя сеть 192.168.0.0/24, сопряженная 192.168.15.0/24, а также живущем на нем VPN сообществе с сетью 172.16.0.0/24.
Все тривиально и просто.
Все вроде просто, да на поверку не очень. Сначала поднял DMZ сетку 172.16.10.0 но почему то тут же упал VPN. Решив, что видимо глюк openvpn, забил и сменил сетку на 192.168.20.0, но ничего не заработало. Ковырялся вокруг да около очень долго, но в итоге часу в третьем ночи, понял, что не работает и естественно решил, что это тот же глюк VPN, так что решил взять вообще нигде не использовавшуюся сетку 10.10.10.0
Стал добавлять юзверя в CentOS, ну и что то не могу понять отчего не работает useradd. Не видит его система. А не работает оно потому, что ifconfig я почему то на автомате пишу как /sbin/ifconfig , а вот добавлялку пользователей нет. Иначе бы заметил еще на стадии настройки сети, что не добавлены переменные окружения /sbin /user/sbin и /usr/local/sbin
Для чего открываем файло в корне юзверя ~/.bash_profile и допрописываем в переменные PATH указанные, а также все нужные нам окружения.
Теоретически указанные файлы (.bash_profile) отвечают за конкретного пользователя, то есть если мы пропишем их только Васе и руту, то видеть эти пути будут вася и рут, а все остальные пойдут лесом. Тогда как для всех остальных пользователей системы, если мы по доброте душевной хотим позаботиться и о них, нам следует прописать переменные окружения в файле /etc/profile, где собственно и пропсаны в том числе вышеуказанные пути
pathmunge /sbin
pathmunge /usr/sbin
pathmunge /usr/local/sbin
НО, учитывая что в 99% случаев работать мы будем через ssh, данный вариант нам не подходит, ибо при старте ssh запускается интерактивный шелл, который игнорит переменные описанные в файле /etc/profile и поэтому отрабатываются только переменные домашней директории пользователя ~/.bash_profile
День радостно прошел под эгидой попытки починить другу iMac, который начал глючить, так что человек не мог на нем работать- ни в винде, ни в Mac OS. И только теперь я по настоящему понял, что означал вопрос суппорта Apple на мой радостный вопрос как поставить Windows на Mac OS- “зачем?”.
Действительно- зачем? Я бы даже сформулировал точнее- зачем покупать Apple Mac вообще, и уж тем более пытаться на него что то поставить. Ибо до этого мне приходилось ставить операционки на яблочные кирогазы, но все это происходило весьма гладко и без проблем. А вот в системе с уже имеющейся Windows- оказалось реальными граблями, причем более муторной установки я не встречал на все время своего знакомства с операционками.
