EdgeMAX - como posso adicionar novos pacotes e recursos para EdgeOS?

Visão geral


Os leitores aprenderão como adicionar novas funcionalidades para a plataforma de roteamento de núcleo EdgeOS. Vamos olhar para o processo por exemplo de Comunidade contribui pacote vyatta-cron (você pode obter uma cópia em https://github.com/SO3Group/vyatta-cron).

EdgeOS/Vyatta é baseado no Debian. Portanto, ele herda o seu sistema de embalagem. Para simplificar o processo, eu criei um pacote dummy: https://github.com/SO3Group/vyatta-dummy

Escolha um nome para seu pacote. Tradicionalmente os nomes começam com "vyatta". Se você deseja criar pacotes separados para operacional e comandos de configuração, chamá-los "vyatta - op-*" e "vyatta - cfg-*". Nosso pacote é pequeno, então não dividimos. Como é um front-end para o cron, seria razoável chamá-lo "vyatta-cron".

Passos


Instale o Debian Squeeze, por exemplo, em uma máquina virtual.

Instale os seguintes pacotes:

sudo aptitude install build-essential devscripts debhelper autotools-dev autoconf fakeroot automake

 
Crie um diretório chamado "vyatta-cron" e copie o esqueleto da vyatta-boneco lá (tudo para além de .git, nós iremos init git do zero). Repositório do git init com

git init

 Adicione o usuário apropriado e e-mail para ".git/config".

[user]
        name = J. Random hacker
        email = jrhacker@example.net

Config para telecomandos depende de sua configuração. Para github é como:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git@github.com:YOURUSER/repo-name.git

Estrutura do pacote


Existem vários subdiretórios e muitos arquivos.

/debian/            # Debian package build specs
    /control        # Package metadata
    /rules          # Package makefile
    /copyright
    /README
/changelog /scripts/ /templates-cfg/ /templates-op/
AUTHORS
Makefile.am
configure.ac

Configure.AC

Isto é o que produz o script configure. A única coisa que você pode querer mudar é a parte AC_INIT.

AC_INIT([vyatta-cron], VERSION_ID, [maintainers@so3group.net])

 Insira seu nome de pacote no lugar de "vyatta-cron" e seu e-mail.

/ debian

Primeiro, edite "debian/direitos de autor" e "debian/README". Eles são simples, substitua o nome original e descrições com o seu.

debian/changelog

Substitua seu conteúdo com a sua entrada "lançamento inicial". Caso contrário causará conflito de nome em tempo de compilação se você manter uma entrada com o antigo nome de pacote lá.

debian/control

Então, o "debian/control". Esse arquivo define o nome do pacote, descrições, dependências e assim por diante. Isto é o que parece no meu pacote:

Source: vyatta-cron
Section: contrib/net
Priority: extra
Maintainer: SO3 Group <maintainers@so3group.net>
Standards-Version: 3.9.1
Build-Depends: debhelper (>= 5), autotools-dev, autoconf

Package: vyatta-cron
Architecture: all
Depends: vyatta-cfg-system,
 vyatta-cfg,
 vyatta-op,
 cron,
 ${misc:Depends}
Description: Vyatta task scheduler configuration
 Vyatta task scheduler configuration utiliites, templates and scripts.

O que você precisa mudar:

  1. "Fonte:". A fonte nome do pacote, que afeta principalmente o nome do tarball fonte gerado junto com a compilação do pacote. Deb. Geralmente é o nome do pacote upstream, mas nós somos nosso próprio montante, então o mesmo para o nome do pacote.
  2. "Mantenedor:". Você e o seu e-mail de contato.
  3. "Pacote:". É que o pacote de binários do nome terá.

"Arquitetura: todos os" significa que o pacote contém apenas os arquivos independente de plataforma. Se o seu pacote tem apenas shell e scripts Perl, é o que você precisa.

debian/rules

Para casos simples há não muito a mudar para lá. Localize a linha que diz "pacote =" e substitua o nome com o nome do pacote. No nosso caso:

PACKAGE=vyatta-cron

 Agora você deve verificar se que seu pacote constrói, faça o seguinte do seu diretório do pacote:

debuild -us -uc

 "-nós - uc" significa "não assino".

Se constrói e produz um. deb no diretório de nível superior, você fez tudo certo. Agora para o código real.

Definir os comandos

Primeiro, acho que será seus comandos. Na maioria dos casos é uma boa idéia para não vincular os nomes de implementação subjacente e estrutura muito perto, acho que de entidades que você está adicionando, declarações de config de back-end não específico.

Nós wil começar com comandos de configuração, aqueles que são executados após "configure" e modificar o config.

Para cron precisamos a única entidade: tarefa. Precisamos ser capazes de definir as seguintes propriedades para isso: intervalo de execução, caminho do executável e argumentos passaram para o executável. Por que dividir o arquivo executável e seus argumentos? Desta forma, seremos capazes de descobrir se o executável existe e poupar o usuário de tempo na solução de problemas. Também, os argumentos são propensos a mudar mais frequentemente do que o caminho do executável, para que o usuário não precisará digitar o nome do executável repetidamente.

Para usuários não familiarizados com o UNIX podemos fornecer sintaxe fácil para intervalos de tempo (a cada 10 minutos, cada hora, etc.). No entanto, é uma boa idéia fornecer temperado expers UNIX com oportunidade de inserir a especificação de tempo completo cron.

Então, vamos converter estas considerações em árvore de comando:

system
    task-scheduler
        task <name>                          # Task name
            cron-spec <UNIX cron time spec>
            executable
                arguments <arguments string>
                path <path to executable>
            interval
                <int32>[mhd]                 # m for minutes, h for hours, d for days

Agora nós precisamos dizer Vyatta comandos que queremos. Vyatta usa "modelos" para ele. Modelos consistem de árvore de diretórios onde o diretório chamado nomes de caminho de configuração do jogo e arquivos especiais chamados "node.def" que definem o comportamento de comand.

Ir ao nosso pacote "modelos-cfg". Remova o diretório de amostra e criar a árvore de diretórios a seguir:

templates-cfg/
    system/
        task-scheduler/
            node.def
            task/

 Cada nível da árvore de diretório precisa de um "node.def", mesmo que isso não define qualquer comportamento (caso contrário, o sistema ignora esse diretório). Por "sistema /" herdamos esse arquivo do sistema (como já é definido pelo pacote vyatta-cfg-sistema), para "sistema /-Agendador de tarefas" temos nossos próprios.

Editar "system/task-scheduler/node.def" e escreva lá:

help:  Task scheduler settings

 Isso ajuda o texto será exibido na conclusão (e dizer que o sistema é um diretório de modelo).

Agora a parte mais complicada. Obviamente precisamos ser capazes de criar múltiplas tarefas. Como? EdgeOS/Vyatta chama nós que podem ter várias instâncias e servem como recipientes para outros nós "nós de marca". Não há sintaxe modelo especial para ele.

task/
    node.def
    node.tag/
        crontab-spec/
            node.def
        executable/
            arguments/
                node.def
            path/
                node.def
        interval/
            node.def

Tudo o que colocamos sob que dir "node.tag" aparecerá em cada instância de tarefa. Agora precisamos criar um node.def para notificar o Vyatta "tarefa" é um nó de marca e como lidar com isso.

Edite "system/task-scheduler/task/node.def":

tag:
type: txt
help: Scheduled task
val_help: Task name
priority: 999
end:
    if [ ${COMMIT_ACTION} == DELETE ]; then
        sudo rm -f /etc/cron.d/vyatta-crontab
    else
        sudo /opt/vyatta/sbin/vyatta-update-crontab.pl --update || exit 1
    fi
  1.  "tipo:" definido permitido o tipo de valor, o sistema recusará definir valores de outros tipos. Os tipos mais comuns são: "txt" — cadeia de caracteres com nenhum formato verificando, "int32" — inteiro não assinado, "ipv4" — único endereço IPv4, "ipv4net" — CIDR IPv4, "ipv6" — único endereço IPv6, "ipv6net" — CIDR IPv6.
  2. "etiqueta:" é o que diz o Vyatta é um nó de marca.
  3. "ajudar:" é a seqüência de caracteres de ajuda exibida na conclusão.
  4. "val_help:" é a seqüência de caracteres de ajuda exibida no segundo nível de conclusão (guia duplo).
  5. "anteriormente:" define onde em commit processo fora subárvore é processado. " 999" significa basicamente"depois de tudo". Fazemos isto porque scripts de usuário são propensos a confiar em estado consistente do sistema.
  6. "final:" é onde definimos o comportamento. É um trecho de shell Bourne que chama scripts externos ou executar ações para configurar o sistema de acordo com os valores definidos diretamente (por exemplo, se você apenas deseja definir valor sysctl, você não precisa script externo provável).

"final:" é muito útil para os casos toda a configuração é tratada pelo script externo, como no nosso caso. Para os casos precisamos de ações diferentes na criação, exclusão ou alteração de valor, existem outras declarações:

  • "criar:" — executado quando você cria nó que não existia.
  • "update:" — executado quando o valor de nó é alterado.
  • "excluir:" — executado quando o nó é excluído.
  • "começar:" — executado antes de qualquer outra declaração.

Agora precisamos também escrever do outro node.def. A maioria deles não é interessante, descreverei apenas nó de "executável/caminho" aqui. É interessante porque seu valor pode ser verificado facilmente em tempo definido, e vamos fazê-lo:

ype: txt
syntax:expression: exec
    "if [ ! -x $VAR(@) ]; then \
        echo \"File $VAR(@) does not exist or is not executable\"; \
        exit 1; \
    fi; "
help: Path to executable

 Nota a "sintaxe: expressão:". É uma declaração de casca (Sim, declaração, então \'s são necessários se você quebrar a linha). Se ela retorna um valor diferente de zero, o comando set falhará.

Comandos do modo operacional

Existem muito mais simples do que a configuração mod. Basta criar diretórios e colocar node.def com conteúdos como:

help: Help string
run: Command to execute

 No cron, temos um script que chama "/etc/init.d/cron restart" configuração "sistema-Agendador de tarefas" que exista.

scripts /

Coloque seus scripts lá.

O script cron é bastante simples, você pode encontrar a configuração API para shell aqui: http://vyattawiki.net/wiki/Cli-shell-api e aqui para Perl: http://vyattawiki.net/wiki/Vyatta::Config

Makefile.am

Agora nós precisamos dizer quais arquivos para levar o processo de compilação e onde colocá-las. Se você não estiver familiarizado com o autotools, pense nisso é como magia (e aprender sobre autotools).

Edite "Makefile.am". Primeiro, precisamos colocar nossa configuração scripts '/ opt/vyatta/sbin' dir, e escrevemos:

sbin_SCRIPTS = scripts/vyatta-update-crontab.pl

 Script de reinício de serviço vai "/ opt/vyatta/bin/sudo-usuários" e escrevemos:

bin_sudo_users_SCRIPTS = scripts/vyatta-restart-crond.sh

Controle de revisão

Não se esqueça de adicionar suas alterações bem sucedidas para git.

Inicialmente, faça:

git add *
git commit

Então você pode adicionar apenas arquivos que você mudou para git avise que você fez:

git add scripts/*
git add Makefile.am
git commit

Evitar ir "git adicionar *" depois que você construiu um pacote como você vai ter um monte de lixo gerado automaticamente no repositório! Sempre adicionar apenas arquivos que você mudou, ou fazer "git limpar" primeiro.

Conclusão

Isto é o mínimo que você precisa para criar seu próprio pacote. Olhe para as páginas wiki para API, para outros pacotes do arquivo GPL e experiência, e muito em breve você será capaz de implementar quase tudo o que você quer.

Notas


Você pode você o sistema de controle de revisão de sua escolha (Subversion, Mercurial, Bazaar, etc), mas EdgeOS e Vyatta desenvolvedores estão usando git, então se você está indo para obter seu pacote integrado a montante, é melhor usar git.