virtualenv

На официальном сайте virtualenv в разделе «Installation» рекомендуется устанавливать virtualenv через менеджер Python-пакетов pip (командой «pip install virtualenv«). Однако далеко не всегда pip установлен в системе по-умолчанию. Я не стал исключением: команду pip система не понимает. Идем на официальный сайт и видим, что pip рекомендуется использовать в пределах виртуального окружения virtualenv. При установке virtualenv, pip устанавливается автоматически. Выходит, официальные сайты обеих программ рекомендуют устанавливать virtualenv через pip, а pip — через virtualenv.

Примечание: есть, конечно, множество других способов установки того и другого (через easy_install, скачивание deb-пакетов или python-установщиков) —  все эти способы также описаны на официальных сайтах или на чьих-то блогах. Но все-таки что-то тянет меня придерживаться рекомендуемых способов от официальных разработчиков.

Если следовать концепции виртуальных окружений — логично использовать pip в пределах virtualenv, а не глобально во всей системе. Тем более нахаляву, что и поставится он автоматически вместе с virtualenv. Значит, прежде всего нужно устанавливать virtualenv. Как?

Лучшее решение — установка из репозиториев (почему-то этот вариант не упоминается на официальном сайте virtualenv).

Python 2.x

1. Для установки virtualenv набираем в терминале:

2. Создаем папку, внутри которой будут храниться папки будущих виртуальных окружений. Лучше всего создать такую папку в пределах своей домашней директории, чтобы не было проблем с правами доступа. Пусть эта папка будет называться «projects«:

3. Создаем виртуальное окружение внутри папки projects. Пусть наше первое виртуальное окружение будет называться «project_one«.

(Аналогично могут создаваться виртуальные окружения для каких-то других проектов).

В результате внутри папки /projects/project_one/ создастся маленькая рабочая среда с папками bin/, include/, lib/, local/, содержащими минимальный «набор джентльмена» для работы — python, менеджеры пакетов pip и easy_install. Сюда же могут доставляться все необходимые пакеты, фреймворки (в том числе Django) и утилиты. В пределах каждого виртуального окружения они будут изолированы друг от друга, не оказывая никакого взаимного «паразитного» влияния.

Примечание: во многих руководствах по работе с виртуальными окружениями рекомендуется выполнять команду virtualenv с ключом —no-site-packages. Применение этого ключа позволяет создавать виртуальное окружение, изолированное от системной питоновской папки site-packages, что повышает степень автономности. Так вот в новых версиях virtualenv указывать этот ключ не обязательно, поскольку в них эта опция включена по-умолчанию.

4. Для активации нужно виртуального окружения нужно зайти в его папку («cd project_one») и выполнить следующее:

После активации командная строка изменится: перед именем пользователя появится название виртуального окружения в скобках «(project_one)имя_пользователя>@имя_компьютера ~«.

Теперь любые команды по установке пакетов (например, «pip install django«) или их удалению будут выполнятся только в пределах активированного окружения.

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

 

Python 3.x

 

NO_PUBKEY. Получение GPG-ключа.

При установке пакетов в Linux, с помощью команды apt-get иногда возникает ошибка вида «W: GPG error: [..] Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY [..]». Обычно такая ситуация возникает после добавления нового репозитория в /etc/apt/sources.list с последующей попыткой установить пакет из этого репозитория.

Причина происхождения проблемы — отсутствие в вашей системе публичного GnuPG-ключа репозитория, из которого вы пытаетесь инсталлировать пакет (который, в свою очередь, подписан данным ключом). Хеш нужного ключа указывается в тексте ошибки после NO_PUBKEY (т.е. на месте второго «[..]»). Именно его и надо добавить в базу apt вашей системы для успешной установки пакета.

Чтобы это сделать, требуется выполнить две команды:

Здесь вместо KEY нужно подставить значение того GPG-ключа, который вы хотите добавить в свою базу. Так, например, если вы получали ошибку NO_PUBKEY F120156012B83718, вам потребуется выполнить следующие команды:

После успешного экспорта GPG-ключа в свою базу вы можете повторить попытку установить нужный вам пакет.

——

есть способ проще и элегантнее, возможно пригодится

дождитесь строк типа

W: Ошибка: deb.opera.com unstable Release: Следующие подписи не могут быть проверены, так как недоступен открытый ключ: NO_PUBKEY ADB4438160A655EF

ADB4438160A655EF — это КЛЮЧ, он разный для разных репозитариев

——

если у вас прокси в сети, то

——

Восстановление IP-фона Cisco 7942G

Cisco 7942G мне подарили товарищи по работе, за что им огромное спасибо и уважение! Угораздило же меня прошивать телефон на SIP-прошивку именно в тот момент, как скакнуло напряжение в офисе.. 8(( Телефон сдох.

После различных попыток восстановления телефона, он замолчал и уже не подавал никаких признаков жизни — на экране по появлялось никаких сообщений. Ни по команде 123456789*0#, ни по 3491672850*# восстановить телефон, с помощью местного TFTP-сервера и прошивок на нем, не удалось. (((

Пришлось менять стратегию.

Был запущен отдельный TFTP-сервер на DHCP с раздачей файла по протоколу BOOTP на Debian 5.0.6. Использовалось редкое в России устройство Synertron CV860A, с процессором VIA C3:

  • CPU VIA Eden/C3 376 PIN 1GHz,
  • PLE133 chipset, PC133 SDRAM memory,
  • 3x LANs, 2x Serial ports, 3x USB ports,
  • 50-pin bootable Compact Flash Disk Socket,
  • 1x DOC,
  • 1x 44-pin IDE,
  • and 1x 40-pin IDE.
  •  

    Крайние правые порты (по порядку): eth0 и eth2.

    Решение нашел благодаря статье на официальном сайте — http://www.cisco.com/en/US/ts/fn/620/fn62949.html

    Вот содержание статьи:

    Workaround:

    Cisco recommends that customers stage their Cisco Unified IP Phones before deploying them to users. This allows Network Administrators to ensure:

    — Each phone is upgraded to appropriate firmware releases.

    — Properly configure the phone prior to deploying each phone

    — The phone is assembled with the appropriate cables, handsets and optional headsets.

    While staging the Network Administrator can perform additional activities such as factory resets, apply Dial Numbers and spot check phone functions.

    Solution:

    Cisco recommends the use of Firmware release 8.2(2)SR1 or later releases. This release and later versions are free of this defect. Registered users may obtain this release from the Cisco Unified IP Phone Firmware downloads (registered customers only) page. Select the proper load for your model of IP Phone.

    Recovery of the IP Phone:

    1. Make sure your phones are on a network with a valid DHCP server.
    2. Make sure the DHCP server on this network has a valid Option 150 setting pointing to a valid Cisco TFTP server.
    3. Make sure you have a valid term11.default.loads file from load 8.2(2)SR1 or higher on the TFTP server that is referenced in Option 150.
    4. Make sure you have all other needed image files present on this same TFTP server. * See note below.
    5. Change the timing on the network — the problem is related to timing. Toggle switch port settings between «Auto» and «100Mbps.» On a Cisco switch the command to toggle the switch port switch:

      Wait 10 minutes, or until all the phones have been updated, then issue the following command if desired to return to original configuration:

      Ensure that items 1 through 5 have been completed. If performing these five steps does not resolve the issue, continue with the remaining steps.
    6. Pull power on the phone (even if power is PoE).
    7. Hold down the # key on the phone.
    8. Continue holding down the # key and re-apply power.
    9. While still holding the # key wait for the Message Waiting Indicator (MWI) light on the handset to start flashing.
    10. Once the MWI light is flashing, release the # key and enter the following sequence exactly on the keypad:3491672850*#Once this sequence has been entered on the IP Phone, if all the network criteria above have been met, it should begin its recovery process. This process can take up to 15 minutes to finish. The phone may appear to be doing nothing during this time. However, if the phone does not recover after 20 minutes then it is possible that the recovery is stuck. In this case, re-examine your network and verify that steps 1-4 are in place, then re-issue the factory reset sequence.

    * Note: The factory reset sequence is a way for a phone to clear flash and still upload to a valid firmware image. This is facilitated by the termxx.default.loads file, but requires that the image files listed in the termxx.default.loads file are available in TFTP for the phone to download. Open the termxx.default.loads file in any text editor. This loads file is essentially just a packing list showing all the OS and application files the phone needs to function. The files include a cnu, cvm, dsp, app and jar files. Please make sure that these files as listed in the termxx.default.loads file are in TFTP. («xx» will be either «06» for the CP-7906G model, or «11» for the CP-7911G model.)

    Additional Diagnostic Steps:

    — Try a hard-coded IP address as a test to see if this resolves the upgrade failures. If it does, and the number of failing IP Phones is relatively few, this procedure may be the most expedient. After the IP Phone upgrades successfully, reconfigure the IP Phone to use DHCP.

    — Try putting the phone on a hub or a different switch and see if this helps change the startup timing enough so that the upgrade completes successfully.

    ***

    Основная проблема возникла в пунктах 1-4, — не сразу удалось подобрать подходящую конфигурацию и заставить ее работать, ниже описываю положительный опыт создания такой конфигурации.

    Первоначально пытался прописать DHCP option 150 на сервере Windows 2003 Server (позже подготовлю статью по этой теме), однако сразу не завелось, потому перешел на Debian.

    IP-фон с помощью порта 10/100SW был подключен к свитчу, свитч подключен к серверу в порт eth0 (192.168.100.0/24), порт eth2 сервера (192.168.0.0/24) через еще один роутер, был подключен к интернету.

    Итак, после установки операционной системы, был установлен TFTP-сервер:

    Устанавливаем DHCP-сервер:

     

    Настройки DHCP-клиента:

    Файл /etc/defaults/dhcp3-server:

    Настройки сети:

    Перезапуск сетевых настроек:

    Перезапуск DHCP-сервера:

    Для пропуска трафика из подсети 192.168.0.0 в сеть 192.168.100.0, настраиваем NAT на IPtables, делаем скрипт ~/fw.start:

    И запускаем его:

    После этого трафик из сети 192.168.0.0 будет доступен и в 192.168.100.0.

    Результаты работы проверяю с помощью tshark:

    После всех манипуляций перезагружаем IP-фон, как описано в статье в пункте 10:

    1. Зажимаем #.
    2. Отключаем питание.
    3. После того, как начинают мигать кнопки Line отжимаем #.
    4. Набираем комбинацию 3491672850*# и ждем, пока с TFTP-сервера пойдет трафик в телефон.

    На TFTP-сервере были размещены файлы одной из ранних прошивок:

    dialplan.xml:

    SEPB8BEBF22BE05.cnf.xml (конфиг-файл от более поздней прошивки):

    XMLDefault.cnf.xml:

    и пустой файл: CTLSEPB8BEBF22BE05.tlv

     

    🙂

    После всего этого, телефон восстановился.

    Предстоит еще обновить прошивку с 8.5.2 до минимум 8.5.4 (для благополучно работы Cisco 7942 с Asterisk 1.4.39 у нас в конторе). Но это уже другая история.

     

    Debian sources.list

    # cat /etc/apt/sources.list

    В Debian 5 используется имя дистрибутива lenny, в Debian 6 используется squeeze.

    Asterisk on Debian Squeeze

    First some background: I use Asterisk to route my calls through multiple VoIP providers. Calls to Australian landlines through iiNet since they’re free, and the rest through Pennytel since they’re cheap. My el-cheapo ATA simply registers with Asterisk and my mum just calls as usual, and everything’s automagically cost optimised.

    Problem: I did an apt-get -y dist-upgrade after not having touched this system for quite a while, and one of Asterisk’s dependencies, dahdi, failed to install with the error message FATAL: Module dahdi not found.

    Basically, the dependecies don’t cause automatic installation of the needed kernel drivers, so the following will fix it:

    source: http://cryptwizard.info/?p=691