Pull to refresh
22
0
Send message
Хорошая статья. Сделал то же самое на двух роутерах openwrt при помощи пакета smcroute.
Прошивка 22.85.
Нельзя прописывать буквы в поле «Телефонный номер», но это поле используется не для регистрации, а для идентификации аккаунта на закладке «Телефон».
В поле «ID линии» можно писать любые буквы. Это поле будет отображаться на экране трубки, когда будет поступать входящий звонок.
В поле «Идентификационный ID» так же можно писать любые буквы. Это как раз является логином, который предъявляется SIP-серверу при регистрации.
«linux maxroot=16 swapsize=16» при установке проксмокса позволяет задать размер root- и swap-разделов.
Как страшно жить.
Надо сделать маршрутизатор VLAN'ов в виртуалке.
Т.е. реализовать схему router-on-a-stick.
Как пучок VLAN'ов пробросить в контейнер или виртуалку?

Ковёр на стене прекрасен
Сдается мне вы выбрали язык иронии.
Спустя 4 года после вашей публикации поднял skype в freeswitch на Debian 7 Wheezy.
С незначительными изменениями в конфигах взлетело.
Спасибо! :)
В принципе да. Тут надо было просто «освободить» /dev/sda1, чтобы потом можно было его добавить в массив. Добавил
root@kvm0:~# umount /boot
root@kvm0:~# mount /boot

Так получится без перезагрузки.
Спасибо за замечание! Мануал поправил.
Перечитываю легенду и не перестаю поражаться: столько работы ради двух дней форума.
Молодцы. Хорошее дело делаете.
В универсальности. При отказе аппаратного райд-контроллера вам нужно будет заменить его на точно такой же, чтобы восстановить работоспособность массива. При отказе компа с софтрайдом просто меняем комп, поднимаем софтрайд и продолжаем пользоваться. Ну и плюс большая производительность софтрайда по сравнению со встроенными fakeraid'ами в материнских платах. Да, если винт вылетает, нужно провести несколько больше манипуляций для вывода плохого HDD из массива и ввод в массив исправного, но это временные неудобства, которые компенсируются остальными преимуществами.
А еще интереснее так :)
watch -d cat /proc/mdstat
По поводу того, кто сделал хаос. Этапы, через которые проходит любая развивающаяся компания, в целом типичны и одинаковы для всех. Поначалу штат сотрудников небольшой и предприятие сосредоточено на том, чтобы войти в рынок и закрепиться на нём. При этом на данном этапе вопросов о какой-либо ИТ-структуре не стоит в принципе. Планирование ресурсов отсутствует, на перспективу никто не загадывает. Задачи ставятся здесь и сейчас и должны выполняться сиюминутно. Всё делается на бегу. Когда своих сил не хватает, появляется потребность в «сисьадмине», который берет на себя сопровождение созданного юзерами зоопарка. Обычно зарплату такому админу ставят небольшую из-за ограниченного бюджета и приходят на неё студенты без какого-либо опыта и видения, как ит-сфера предприятия должна развиваться дальше.

В отсутствие опыта работы у исполнителя и бесконечного числа разношёрстных задач, которые валятся на неокрепший подростковый ум, еще не родившаяся ит-сфера предприятия начинает месяц за месяцем впитывать в себя токсины лоскуточных «наколенных» решений. Затем в один «прекрасный момент» один админ уходит и на его место приходит другой. Теперь перед ним стоит задача сопровождения унаследованной костыльной архитектуры, миграции и развитие имеющихся сервисов (а чаще их надо переделывать, потому как предшественник сделал всё для того, чтобы они оказались мертворожденными и на них уже ничего не построить). Вся ситуация усугубляется низким уровнем лояльности со стороны сотрудников к админу, как к представителю профессии. Со всем этим ему приходится бороться, устраиваясь на новое место. Еще год-два подобной «текучки» админов в конторе и ИТ-сфера превращается в нечто совершенно неуправляемое. То, что можно было сделать раньше за время t, сейчас уже требует времени t*3. Админ начинает тонуть в суппорте внедренных ранее решений, оказываясь неспособным повлиять на дальнейшее развитие событий. Ситуация в ИТ-сфере превращается из неуправляемой в кризисную. Если компания к этому времени каким-то образом смогла встать на ноги и заработать достаточно денег для решениях проблем, на которые раньше все закрывали глаза, то следующим шагом вероятнее всего станет привлечение в компанию высокооплачиваемых специалистов со стороны. Как ни смешно, но в отличие от предшественников, их будут слушать хотя бы уже только из-за того, что платят им большие деньги. ))

Кто виноват в таком развитии ситуации? Неграмотный админ — полбеды. Неграмотное руководство — катастрофа. В любом случае определением того, в каком направлении идёт развитие предприятия, в первую очередь занимается руководство, а не админ. Стать грамотным ИТ-директором в компании, которая родилась и развивалась в хаосе, дано далеко не всем.
Как замечательно: теоретики дают советы практикам.
С точки зрения руководства, с которым ты разговариваешь, есть 10 человек, которых всё устраивает (саботажники), и есть 1 человек, которого не устраивает (собственно админ). Аргументы должны быть настолько железо-бетонными, чтобы 1 человек мог противопоставить своё мнение мнению большинства, чтобы в результате все сделали именно так, как он говорит. Речь в основном об этом. На практике количество людей напрямую заинтересованных в том, чтобы все осталось так как есть (недальновидная стратегия серых масс) перевешивает мнение одинокого воина.
Неистово плюсую за озвученные проблемы, с которыми РЕАЛЬНО сталкиваются люди, работающие в ИТ-сфере. Сам 3 года работаю на аутсорсе в компании из 100 человек, в которой хаос, разброд и шатания, начиная с руководства и заканчивая уборщицей — это в порядке нормы, а порядок и стандарты — сказки изумрудного города. Делать из говна конфетку это как раз то, чем я занимаюсь всё это время. Поэтому и говорю, что всё, о чем написано в статье, хороший roadmap для небольшой конторы, но он с треском проваливается, когда на месте есть админ-побегушка, которому надо семью кормить, отлизывая всем, кто попросит, вместо того, чтобы соблюдать какие-то стандарты, которые позволят сохранить свою работу завтра. Все живут одним днём, какое им дело до того, что будет через год. Никого не волнует. «Всё ведь и так работает». ))
Да нет, написано-то всё хорошо. И даже многое бы я взял на заметку с точки зрения того, каким языком можно доносить до руководства необходимость ухода от унаследованной разрозненной инфраструктуры. Потому что все более-менее опытные админы с комплексным подходом к решению задач всё вышеизложенное понимают чуть более, чем хорошо. Другое дело, что описана скорее теория из разряда «как должно быть» вместо «success story». Потому что на практике скорее будет, что директору на уши присядут 10 сотрудников недовольных «нововведениями» и все благородные планы админа по «наведению порядка» так и останутся планами. Либо он идет против всех, рвя рубаху на груди за правое дело, либо вспоминает, что у него дома жена и дети и плывёт по течению — «а не буду-ка я ни с кем спорить… да как бы меня не уволили еще… а что я тогда кушать буду...». В своей жизни я больше встречал людей второго типа, чем первого, поэтому и говорю, что написано-то всё красиво и правильно, но между этим планом и реальностью часто большая пропасть для преодоления которой мало только говорить, нужно еще и делать.

Information

Rating
Does not participate
Registered
Activity