Como atualizar o aplicativo XYZ no meu TKL appliance [para novos Linux]

...trabalho em progresso... Eu originalmente me propus a tornar isso simples e fácil de ler para newbs, mas tem muito mais cheio do que o pretendido...

Para informações sobre a instalação de aplicativos via gerenciamento de pacotes (ie apt) consulte Aqui.

Esta é uma pergunta complicada que provavelmente irá exigir uma resposta específica para cada aplicativo individual que você deseja instalar ou atualizar / atualizar. Infelizmente, isso está além do âmbito deste "como-para" e vai exigir trabalho adicional da sua parte. Você pode ter sorte e encontrar um caminho manual de instalação ou atualização/atualização foi documentado por um membro anterior da comunidade TKL (tentar pesquisar os fóruns - canto superior direito) se não, Por favor, continue a ler. Esta página inclui uma explicação das principais formas como os aplicativos são instalados pelo TKL core devs, uma justificativa do porquê eles fizeram isso dessa forma, e quais as medidas gerais que você pode precisar para dar instalar ou atualizar/atualizar o aplicativo individual em seu TKL appliance.

Antes de começar

Eu recomendo que você comece com a versão TKL appliance atual (v11.3 como no momento da escrita). Eu também recomendo fortemente que você documento de perto cada passo enquanto você vai. Torna mais fácil solucionar problemas se você não obter imediatamente os resultados desejados. Também quando você terminar, você pode compartilhar sua documentação passo a passo completa com a comunidade - como todos os bons cidadãos de código aberto deveriam! :)

Para usuários sem appliance atual com dados existentes, pule direto para o próximo cabeçalho. Se você tem dados atuais em um appliance e se você não estiver usando pelo menos v11.x, eu sugiro fortemente que você cuidar disso primeiro. Em seguida, faça um backup completo (TKLBAM funciona bem para mim) e fazer uma restauração de teste para uma instalação limpa (VMs são úteis para tarefas como esta).

Alguns aplicativos podem exigir que você migre manualmente os dados ao atualizar/atualizar versões. Isso será mais frequente quando se fizer atualizações de versão principais - por favor, verifique a documentação do aplicativo relevante (esperançosamente que seja em seu site). Sugiro que faça um teste da atualização desta VM antes da sua instância principal.

No pior cenário, você pode usar seu backup TKLBAM para começar de novo do zero, sem danificar sua instância atual em execução.

As principais formas de instalação dos aplicativos

As principais maneiras que o núcleo TKL devs instalar aplicativos ao fazer appliances são:

• Gestão de pacotes, ou
• Arquivos a montante (muitas vezes designados por "tarballs"). Estritamente falando tarballs são apenas arquivos tar.gz (ou tar.bz2) mas às vezes o pacote de desenvolvedores upstream como arquivos zip em vez (que tecnicamente não são tarballs). Para os fins desta documentação tarballs refere-se a qualquer arquivo de app fornecido upstream.
• Outro código-fonte a montante. Os devs AFAIK TKL geralmente não instalam nada dos repos de controle de versão upstream (por exemplo, SVN/Git/Mercurial/etc) e/ou compilam manualmente o código fonte, pois estes não são frequentemente estáveis. Embora eu tenha notado que cada vez mais alguns desenvolvedores optar por também fornecer branches estáveis através deste meio (então eu escolhi incluí-lo).

Gestão de pacotes (repo oficial)

Estes aplicativos são instalados usando o apt-get install <packagename> comando e (geralmente) virá dos repositórios oficiais do Ubuntu. Geralmente, esses pacotes são mantidos na mesma versão principal que no momento do lançamento (ou seja, abril de 2010 no caso do Ubuntu 10.04 - a base do TKL v11.x). Para mais informações sobre a utilização do apt see Aqui.

Para adicionar à confusão também há um funcionário, mas não oficialmente suportado Ubuntu repo chamado 'universo'. Os pacotes neste repo não são atualizações de segurança garantidas (embora eles possam receber patches comunitários fornecidos e existem algumas exceções, como MediaWiki). Há também outro Ubuntu repo oficial chamado 'backports' (que novamente não é oficialmente suportado) que contém versões mais recentes/atualizadas de software do que o que enviado originalmente. Embora este pode parecer um meio feliz, em minha experiência não há raramente nada de interesse em lá, mas YMMV.

Prós

Apesar de as principais versões destes aplicativos não serem atualizadas, isso não significa que eles não sejam atualizados. Geralmente todos os bugs relacionados à segurança são backported (e ocasionalmente outras correções de bugs graves também) - para aplicativos no 'main' repo de qualquer maneira (as atualizações aparecem em 'segurança'). Estes serão aplicados automaticamente através do mecanismo de atualização de segurança automatizado da TKL.

Este processo de instalação e atualização/atualização maximiza a segurança e a estabilidade e minimiza o risco de ocorrência de problemas inesperados. Também minimiza as despesas gerais de manutenção, levando a um aumento da produtividade. Os riscos de os dados serem corrompidos ou inatividade para o seu appliance são muito limitados (embora obviamente ainda seja melhor manter backups regulares - apenas no caso).

Portanto, a menos que haja uma necessidade genuína para a versão mais recente (por exemplo, um bug 'show-stopper' ou um recurso necessário) é geralmente preferível deixar esses aplicativos como eles são. Os usuários de Windows novos para Linux podem encontrar isso é contrário ao seu processo habitual de atualização sempre para a versão 'mais recente e maior' de software, mas em muitos cenários é realmente Melhor!

Contras

O lado negativo é que novas funcionalidades quase nunca são adicionadas e pequenos bugs (e às vezes até mesmo os maiores) não são abordados (até a próxima versão principal do TKL - onde o aplicativo número de versão muitas vezes saltar consideravelmente). Também software de auditoria de segurança simplista (que apenas verifica os números de versão de software) muitas vezes listar falsamente aplicativos como sendo 'insegura' e tendo vulnerabilidades quando, de fato Foram remendadas, ou seja, falsos positivos.

Também às vezes aplicativos instalados como este pode ser um pouco confuso para ex Windows Linux newbs como em vez de tudo estar no mesmo lugar (por exemplo, em uma subpasta da raiz web) eles podem ser espalhados em alguns lugares diferentes através do sistema de arquivos Linux (por exemplo, geralmente arquivos de configuração serão encontrados em /etc/<appname>). TKL tenta mitigar isso, fornecendo links simbólicos para onde os dados estão.

Gestão de pacotes (repo de terceiros)

Os devs AFAIK TKL não fornecem atualmente nenhum appliances que contenha aplicativos de terceiros. Quando disponível, pode ser uma boa maneira de ir se um terceiro fornecer um repo que inclui um aplicativo compatível.

Às vezes você terá sorte o suficiente para que os devs upstream do aplicativo desejado fornecer seu próprio repo. Este repo pode ser hospedado em seu próprio site, ou talvez em algum lugar como um PPA (Arquivo de Pacotes Pessoais) no LaunchPad. Às vezes você pode encontrar um terceiro (ou seja, alguém não envolvido com os devs upstream) irá produzir seu próprio repo (mais provável de ser um PPA, mas pode não ser). Pessoalmente, eu geralmente tive bons resultados com LaunchPad, mas pode ser atingido e falhar.

Prós

Os acordos de recompra de terceiros são geralmente atualizados com muito mais frequência do que os acordos de recompra oficiais (embora isso dependa do terceiro). Os acordos oficiais de recompra (PPAs ou de outra forma) são geralmente seguros e confiáveis e (geralmente) fornecem mínimo alarido para atualização de aplicativos. IMO estes podem muitas vezes ser ainda melhores do que os acordos oficiais Ubuntu.

Contras

Se não forem oficiais, os acordos de recompra de terceiros podem ser de qualidade e confiabilidade desconhecidas. Você não tem nenhuma forma real de saber quando ou se eles podem ser atualizados novamente.

Tarballs a montante (e outra fonte)

Como sugerido acima, tarballs upstream são arquivos contendo todos os arquivos necessários para instalar o aplicativo. Estes são fornecidos diretamente pelo desenvolvedor upstream. Estes são bastante muitas vezes genéricos na natureza, mas geralmente terá algum tipo de requisito mínimo. Webapps (ou seja, aplicativos que são executados em um servidor web eg MediaWiki) são muito comumente fornecidos como este. Antes mesmo de considerar atualizar para um tarball upstream você vai querer verificar novamente que tudo o que ele requer pode ser facilmente satisfeito pelo Ubuntu 10.04 (na minha experiência isso é geralmente o caso com aplicativos mainstream embora YMMV). Se você estiver atualizando um TKL appliance existente que usa um aplicativo do gerenciamento de pacotes, você provavelmente precisará removê-lo. Em alguns casos, pode até ser preferível começar com uma instalação LAMP de baunilha (em vez de atualizar um appliance existente).

Prós

Tarballs Upstream sempre terá a versão mais recente do software e incluirá todas as características mais recentes (bem como todos os bugs mais recentes :p). Muitas vezes, desenvolvedores upstream terão 2 branches: stable (este será o que você deseja para a produção) e desenvolvimento (este pode conter algumas novas características de ponta legais, mas Também pode estar inacabado e/ou conter erros). Isto é especialmente relevante se eles fornecerem a sua fonte através de um repo de controle de versão (como SVN ou Git, etc).

Contras

Uma vez que você vá para uma versão upstream você precisará aplicar manualmente todas as atualizações futuras como eles são liberados. Assim, embora a ideia de ter o "mais tarde e maior" possa ser atraente, você também precisa considerar os custos de manutenção e riscos de segurança aumentados (se bugs de segurança não são endereçados manualmente rapidamente à medida que surgem). Para um pequeno site, com poucos dados importantes e um bom regime de backup, um risco de segurança aumentado e um pouco de manutenção extra usando uma fonte upstream pode ser um sem cérebro. Especialmente se houver bugs de paralisação de show e/ou novos recursos necessários que não ocorram na versão pré-embalada (ou quando não houver nenhum!).

Como dito acima, a menos que você tenha uma boa razão, você está melhor se furando com a versão do Ubuntu repos oficial.

De onde os devs TKL instalam e por quê?

Quando o núcleo TKL devs libera um appliance eles levam estes fatores em consideração e decidem se devem incluir a versão pré-embalada (quando disponível) ou o Versão upstream. Por exemplo, em appliances, como MediaWiki, os devs decidiram que a versão pré-embalada é adequada e assim deixou- a assim. Com o Moodle, os devs decidiram instalar a partir do montante, pois a versão pré-embalada (v1.9) tinha alguns bugs muito sérios, e a nova versão upstream (v2.0) tem alguns novos fortes características (além de Moodle está disponível apenas no 'universo' repos - ver outras considerações abaixo para explicação). Em alguns outros casos (como Redmine IIRC) a versão pré-embalada é tão antiga e faltando tantas funcionalidades que não há muita escolha, mas para usar upstream. Algo, como Joomla não estão disponíveis via Ubuntu, então a única maneira de oferecer é usar upstream.