Comme vous le savez CentOS 5 EOL est (Fin de vie) du 31 Mars 2017. Ce qui nous amène au problème suivant très intéressant:

# yum update
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
removing mirrorlist with no valid mirrors: /var/cache/yum/extras/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: extras

 

Le problème est que de courtes listes de miroirs CentOS 5 coups de pied déjà et tenter d'obtenir directement le contenu obtenu après le refus:

# curl 'http://mirrorlist.centos.org/?release=5&arch=i386&repo=os'
Invalid release

 

Dans l'ensemble l'idée générale plus prudent de réinstaller l'étain avec une distribution normale qui prend en charge la mise à niveau distributive de travail. Malheureusement, le mien est pas le cas et il ne se distingue pas en option sur la table. Nous avons donc dû jouer un petit plan gitan – commencer à utiliser Miroir Vault. Au moment de la créature et le bon sens tout à fait clair savoir, Je ne aucune mise à jour qui ne sont pas le but de l'exercice, et que vous voulez juste avoir travailler avec yum pour installer le paquet que j'ai besoin. A cet effet, a commenté toutes les variables mirrorlist et ajoutez baseurl dans /etc/yum.repos.d/CentOS-Base.repo. Enfin, nous obtenons repo yum sur le type de

[base]
name=CentOS-$releasever - Base
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
baseurl=http://vault.centos.org/5.11/os/i386/
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#released updates
[updates]
name=CentOS-$releasever - Updates
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
baseurl=http://vault.centos.org/5.11/updates/i386/
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
baseurl=http://vault.centos.org/5.11/extras/i386/
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

Enfin jouer un yum clean all && mise à jour yum. Si tout s’est terminé sans faire d’erreur donc nous avons complété avec succès le régime et nous pouvons en toute sécurité installer vos paquets obsolètes.

 

Mdadm est mon ami bien-aimé mais quelque chose qui irrite beaucoup – des inspections périodiques et resink la santé sécurité de matrice RAID- par exemple, il existe des données dans un secteur défectueux- et, qui à son tour écrasé par la machine pour les e/s. Fondamentalement après j’ai trouvé čoplene coupable – branches qui commencent généralement autour de 13:00 tous les dimanches soirs. L’idée est claire – sûr que le tableau est en très bon état et il n’y a pas des drames avec les informations. C’est bon, mais il semble beaucoup hebdomadaire, C’est pourquoi il prekonfigurirah à r″nva de la première date du mois.

Pour chemin de Redhat dérivés de Krone /etc/cron.d/RAID-Check. Pour Debian basé chemin de distroci /etc / cron.d / mdadm. Kronovete à son tour appelé scripts bash /usr / sbin / raid contrôle pour CentOS, etc. et /usr / share / mdadm / checkarray pour Debian et amis. Paramètres pour les scripts sont tirées /etc / sysconfig / raid contrôle ou, respectivement, /etc / default / mdadm où vous avez peut être interdit complètement et vérifier, ce n’est pas une idée très intelligente.

 

Toute personne qui s’occupe de l’hébergement professionnel sait ce qu’une menace qu’ils représentent infecté par des logiciels malveillants, les utilisateurs, coquilles de Web etc.. L’obšiât cas est utilisée h pas un mauvais script. Il se distingue par 3 choses

  1. Terriblement lent
  2. C’est horriblement lent et si vous le déposez dans le régime de surveillance salira avec votre serveur
  3. Maintenir votre propre base de données avec md5/hex definici pour mauvais code.

Juste son dernier long métrage rend utile, comme vous pouvez s″bmitvaš les fichiers qui n’ont pas été détectés jusqu'à présent et à un stade ultérieur entrera dans la base de données. Comme j’ai partagé dans la section 1 et 2 sa vitesse est scandaleusement basses – à faible charge du fichier machine 70 k sont analysés pour environ une heure et demie. Pour cette raison, j’ai commencé à aider mon bon ami par ShadowX Martin – une alternative à le maldet, écrit en python avec un peu plus de flexibilité. Malheureusement, par manque de temps (principalement mais pas seulement) Nous ne sommes pas un projet fini, qui pour le moment n’est pas très utilisable – Il y a quelques bogues qui doivent être nettoyées. Au cours des derniers jours, j’ai eu des problèmes avec les clients infectés par CryptoPHP qui avaient les fichiers énormes public_html ~ 60 k + Léo-utilisateur. Étant donné que le total devait être analysé plus de 200 fichiers k qui en rough comptes prendrait 5+ heures, que j’ai décidé de Nip/Tuck maldet configuration, afin de réduire les fichiers qui seront analysés à un nombre plus raisonnable et le temps. Tout en čopleh konfa, j’ai remarqué les lignes suivantes

# Attempt to detect the presence of ClamAV clamscan binary
# and use as default scanner engine; up to four times faster
# scan performance and superior hex analysis. This option
# only uses ClamAV as the scanner engine, LMD signatures
# are still the basis for detecting threats.
# [ 0 = disabled, 1 = enabled; enabled by default ]
clamav_scan=1

Intéressant… Apparemment, il est possible d’utiliser le ClamAV – qui est aussi distingué par sa grande vitesse, mais pourquoi ne pas essayer. L’il installe rapidement

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

/scripts/check_cpanel_rpms --fix --targets=clamav

Je lance maldet et cliquez sur le petit dossier – Je ne vois pas une différence dans la vitesse et le comportement – Il a utilisé son scanner de perl-ski au lieu de clamav. Après une brève plonger par la source, j’ai trouvé maldet les lignes suivantes

 clamscan=`which clamscan 2> /dev/null`
 if [ -f "$clamscan" ] && [ "$clamav_scan" == "1" ]; then
        eout "{scan} found ClamAV clamscan binary, using as scanner engine..." 1
    for hit in `$clamscan -d $inspath/sigs/rfxn.ndb -d $inspath/sigs/rfxn.hdb $clamav_db -r --infected --no-summary -f $find_results 2> /dev/null | tr -d ':' | sed 's/.UNOFFICIAL//' | awk '{print$2":"$1}'`; do

Oui j’ai fait un quel clamscan et à ma grande surprise, je trouve que ClamAV est pas dans un chemin, mais muet Cpanel laissé que dans / usr / local / cPanel / 3rdparty / bin / où il a utilisé binarkite. A En rapide résoudre le problème:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

Dans rescan maldet haut déjà rapporté

{scan} found ClamAV clamscan binary, using as scanner engine...

Une fois utilisé maldet ClamAV termine la numérisation de votre 3-4-5 fois plus rapide qu'auparavant. tests ont montré – 70k-INOD et frotter autour 25 min qui est d'environ 3 fois et demie plus vite que le prieur.

Avant de commencer avec une autre haine aléatoire vers 50 avec OS ’ trouvé qu’à l’intérieur de la grotte, je veux dire, qui chaque jour doivent administriram lui et connais assez bien de la première personne du singulier. Aujourd'hui j’ai pris mon temps pour iztestvam la mise à niveau de fonctionnalité nouvelle magique distrubitiven inconnu et invisible (Pseudo) 😀 . La première chose qui m’a étonné est, que RedHat dans leur infinie sagesse ont décidé de cesser la prise en charge pour le x 86 architecture 🙄 . Je suis pleinement conscient que nous sommes en 2014 et les processeurs du serveur 32 longueur de bits est manque d’instructions. Oui, mais qu'est-ce que les utilisateurs de petites et VPS – h64 patte plus de RAM, Cependant, vous le regardez si vous mince machine virtuelle avec 512 Mo-1 Go de RAM se battra pour chaque megabaj hors de lui et je ne vais pas perdre 20-30% d’elle juste à utiliser sur le grand jeu d’instructions. Prepsuvah comme je l’ai instalil x 86 et CentOS tiré un h64. Immédiatement, j’ai vu une différence de sensibilité ISO – ~ 100 Mo au minimum 6.5. Prepsuvah une fois de plus. J’ai installé à nouveau comme virtualkata a décidé de voir comment bien le RedHat ont fait leur travail – J’ai pris/var et / partitions LVM d’usr 😈 individuels . Après l’installation, j’ai mis à jour tous les paquets que j’ai installé apache et, php, bind et mysql – C’était intéressant si ils s″rvisite. J’ai ouvert un guide de bon élève de CentOS pour la mise à jour et a commencé avec diligence à le suivre étape par étape. Quand je suis arrivé le moment de commencer la réelle mise à niveau cette excuse bâclée Millennium, J'ai un problème critique 🙄 . Examinez la sortie détaillée – Yo/usr ne peut pas être sur une partition séparée, j’ai su 😆, vous ne serez pas déçu par Jim Whitehurst et compagnie. En plus de “extrême” Il y avait beaucoup de messages de problème pour les packages non signés, konfizi dossiers de ne pas correspondre, etc... WTF je n’ai même utiliser 3e que tous les référentiels de leurs miroirs tiré vers le bas, que je n’avais pas fait tous les réglages juste une simple yum installer. Il était déjà clair alors très franchement forsirah mise à niveau. Qu’elles gèlent retour diligemment me demande finalement le script et c’est plus pour / usr actions. J’étais trop paresseuse, J’ai essayer de fiksna, Quoi qu’il en soit, c’était uniquement à des fins de recherche scientifique il n’y a aucun produit à serveur nadgraždam pour le moment. J’ai attrapé mon virtualkata j’ai réinstallé cette fois tout ce que je l’ai poussé dans 1 Partager. Aussi, j’ai pris une leçon, ne met à jour toute s″rv″si supplémentaire, Après l’installation d’une mise à niveau directe. L’étape finale est venu à nouveau de dialogue dosaniât qui m’a, J’ai un problème assez élevé – Paquets non valides, konfizi et si sur et ainsi de suite mais peuvent continuer. Je savais dès le départ qu’ils ne les font pas comme si vous avez des choses. Il gèle et attendu pour le – Oh ce qu’un miracle, la mise à niveau terminée avec succès. Et tout a fonctionné, ou du moins le chargeur de démarrage et j’ai essayé d’installer des paquets supplémentaires, mais son commandement stopper zavisvaše – hein a toujours eu à bug 💡 . Après cela, l’ensemble bondé j’ai décidé d’installer un Centos propre 7 voir si il grogne pour partition LVM dans / boot – 6.5 ne permet pas cette audace. J’ai commencé mon ISO et j’ai été légèrement choqué par l’installateur – Il n’était pas très pratique “mettre de l’ordre”, mais afin de pleinement est belle. Après une lutte, j’ai réussi avec le but caressé et oui pour installer le joint d’étanchéité, Vous devriez mettre out/boot-et au-delà-👿 un LVM c’est extrêmement grave et pas ennuyeux, Si pour une raison quelconque, vous avez oublié d’augmenter la taille de la partition de démarrage de 200 Mo et certains noyaux anciens ce qui se passe.

Fondamentalement, je ne m’attendais à quelque chose et je suis toujours déçu dans CentOS.

Comme CentOS et RHEL malédiction merde- et il sont a certaines choses qu’ils ont inventée assez lettrés. Par exemple, l’ajout d’un grand nombre d’IP supplémentaires est tout à fait un beau travail. По принцип ако трябва да добавя голям брой адреси бих си разписал едно bash скриптче в което в цикъл да извършва въпросната операция че на ръка не си е работа. Sous Centos/RHEL personnes ont compris il file assez belle gamme. Fondamentalement nous créons le fichier/etc/sysconfig/network-scripts/ifcfg-eth0-range0. Ici, remplacer eth0 par le nom de la carte réseau si ce ne eth0. Ensuite, ajoutez le contenu suivant

IPADDR_START=192.168.0.129
IPADDR_END=192.168.0.254
NETMASK=255.255.255.128
CLONENUM_START=0

les arguments sont

  • IPADDR_START – adresse IP initiale
  • IPADDR_END – adresse de fin
  • NETMASK – masque de sous-réseau
  • CLONENUM_START – la numérotation à partir de laquelle commence l'adaptateur réseau eth0:0 dans notre cas