Como você trabalha com servidores antigos?

Question

Recentemente, comecei a trabalhar mais em servidores LAMP, o que é muito novo para mim. No começo, não foi um problema migrar meus arquivos de preferências, mas conforme cresci e aprendi mais, minhas preferências e fluxo de trabalho se tornaram mais específicos (e menos portáteis *). Esta manhã me pediram para trabalhar em um antigo servidor Red Hat 4 e é ... é tão antigo que não sei o que fazer com ele. Vim 6? Tudo instalado através do RPMForge? Não é possível instalar tree sem ter que adicionar repositórios? Nenhuma conta de usuário real, exceto root? /sbin/ e /usr/sbin/ não estão nem no caminho do usuário raiz?

Essa coisa foi instalada uma vez e nunca foi modificada. Cada pacote instalado é da era do gelo. A primeira era do gelo.

Então, o que você faz nessa situação? Devo me preocupar em tentar trabalhar no no servidor, ou há uma maneira melhor de fazer isso?

* - a única coisa que quebrou foi o suporte ao tema de cores Jellybeans e o uso das guias do Vim.

edit - Eu acho que a maneira que eu postei não estava clara, mas a ênfase na pergunta deveria estar em você . O que estou realmente tentando entender é o que outras pessoas fariam em uma situação semelhante.

Lembre-se: estou consultando. Não é meu trabalho reinstalar o servidor. Não é meu trabalho fazer uma auditoria de segurança e endurecer o servidor. É meu trabalho tomar vagas exigências de um cliente não técnico executando um servidor muito antigo e fazê-las acontecer no menor tempo possível. É isso aí.

Sou um desenvolvedor, não um administrador de sistemas; é tudo muito novo para mim, e colocá-lo em prática corretamente levaria mais tempo do que posso gastar. Está em produção há anos; Eu estou apenas fazendo modificações.

Eu quero que este servidor seja melhorado? Claro! Eu quero que este projeto seja algo de que me orgulhe? Sim! Isso vai acontecer? Não. Estou mantendo um software antigo no qual não tenho muito interesse e nem recebo muito tráfego. Eu só quero fazer a tarefa de uma forma confortável, sem muito trabalho.

edite 2 - depois de pesquisar um pouco e brincar, acabei montando o que eu preciso localmente com sshfs e MacFuse. Dessa forma, posso ficar no terminal e usar uma mistura de ferramentas locais e remotas com base no que estou fazendo.

    

Answer 1

Você deve entender como usar ferramentas unix comuns (ish). O vim pode ter mudado entre o redhat 4 e o redhat 300, mas aposto que o vi é o mesmo (mesmo que estejam usando o vim como substituto do vi, os comandos do vi funcionarão como esperado). As ferramentas de pacote podem não ser familiares para você, mas aposto que você ainda pode fazer o download de um arquivo tgz, ./configure , make , sudo make install it.

Aprender sobre os melhores e mais recentes é ótimo, mas você também deve aprender as ferramentas nas quais suas ferramentas são desenvolvidas. Existem coisas em unixland que permanecem razoavelmente constantes, e se você conhece e entende como trabalhar com elas, você se sentirá mais à vontade em qualquer variante que acabe, independentemente da idade (dentro da razão aqui as pessoas).

A árvore não está instalada? Aposto que grep, find, awk e sed são. Estes são seus amigos.

Como uma alternativa ao cygwin / etc, não é difícil instalar o VirtualBox e configurar uma caixa Linux em um ambiente virtual que você possa usar para o seu desenvolvimento, e enviar arquivos para o servidor posteriormente.

    

Answer 2

Entre no modo "malditas crianças".

Suas ferramentas devem ajudá-lo a realizar seu trabalho com mais eficiência, sem impedi-lo de entender o que está acontecendo. Realmente, o RH 4 não é tão antigo e é basicamente semelhante ao que existe hoje. Pode não ter o mais recente e melhor, mas deve ser suficiente para fazer o que você precisa (o que é que você precisa).

Rant over.

Por outro lado, se isso está acontecendo na rede, ele realmente precisa ser atualizado com pelo menos os pacotes mais recentes da RH 4.

    

Answer 3

A maioria dos profissionais de serviços eventualmente chega a um ponto em que se sentem à vontade para dizer aos clientes "Sua configuração atual é errada / perigosa. Não vou tocar nela sem acertar".

Embora possa ou não ser jurídica ou moralmente correta, do ponto de vista prático, as pessoas não técnicas vão culpar a última pessoa que trabalhou em um sistema que falha. Se você é a última pessoa que fez login em um servidor que foi comprometido ou que parou de funcionar, é provável que você seja culpado pela falha, mesmo que as coisas que você alterou (ou apenas olhou) não tenham nada a ver com o fracasso.

Isso é mais óbvio com as coisas físicas (imagine ir a uma loja de pneus com pneus carecas e pedir que os pneus carecas sejam remendados, ou ir a uma loja de freios com os freios de todas as 4 rodas e pedir que eles consertem apenas 1 conjunto de rodas, ou pedindo à companhia de gás para reacender a luz piloto em um aquecedor de água perigosamente enferrujado) os mesmos princípios e considerações se aplicam com software e servidores.

Parece que seu cliente tem pelo menos dois problemas: um ambiente de servidor não-mantido, e eles têm os ambientes de desenvolvimento e produção operando no mesmo hardware físico, portanto não é possível modificar um sem afetar o outro.

Se você fingir que é uma maneira razoável de executar as coisas, espera-se que você corrija isso quando explodir, e provavelmente será esperado que você o faça de graça, porque é obviamente sua culpa que falhou em tudo.

Para responder diretamente à sua pergunta, eu diria ao cliente que o sistema de hardware compartilhado é um problema que precisa ser corrigido e que o ambiente de servidor não mantido é tão antigo que é mais barato pagá-lo para mover os dados existentes. um novo sistema versus rastrear todas as mudanças e dependências necessárias para atualizar o sistema antigo. Eles devem (a) obter novo hardware para executar o sistema de desenvolvimento e (b) instalar software atualizado no novo hardware e, em seguida, migrar o desenvolvimento para esse novo hardware. O bônus que você recebe para consertar o problema de hardware compartilhado é que você pode testar o novo ambiente de desenvolvimento antes de fazer o movimento, o que deve proporcionar uma transição mais elegante.

    

Answer 4

Sua escolha é atualizar todos os pacotes e adicionar novos repositórios ou apenas fazer backup dos dados e sites e reinstalar o servidor.