|
Post n°66 pubblicato il 24 Febbraio 2023 da taichung
Problem: I have a Debian vm on Proxmox which lately suffers weird problems which cause the block of the OS. The vm is very old. Originally a Virtualbox 32 bit vm, then moved to KVM/qemu and migrated to 64 bit (kernel+packages). Therefore I decided to try to clone it. The clone is "hot" because you don't need to shutdown the source VM; however, to avoid some trouble, it will be better to STOP the running unnecessary services. I did this on the same Proxmox host. First I created a new Debian vm with a HD of same size as the original, and SAME version of the OS. On the source (old vm), I stopped all the services which keep writing on the disk (excepted those like logrotate,rlog, syslog etc. which I don't care about): servers for database, email, firewall... I left sshd to allow me to connnect to the machines and check what's happening (btw, in case of failure you can still try to use the console embedded in Proxmox). On the source I created a list of installed packages, copied that list on the new vm and used it to install all the same packages (check for my previous post on this blog); be sure to have the same rsw repositories on both machines. On the source vm I created a file, called for example "excludedpackages.txt) with the following content: /boot You can add other paths in case of need. With both vm running and connected to my LAN (so that I can ssh into them from a third PC), on the old vm, as root user, I run in a terminal: $ rsync -vPa -e 'ssh -o StrictHostKeyChecking=no' --exclude-from=/root/excludedpackages.txt / DESTINATIONIP:/Obviously you need to change "DESTINATIONIP" with the login and real IP address of your destination VM. The system will ask you for the password of the user on the destination vm, then the synchronization will begin, and take some time. Once finished (hopefully without errors, otherwise you can try again) you can turn off the old vm. Optionally modify the IP address of the destination vm so that it can have the same of the original, old vm; by doing so, you can avoid to tell all the computers of your LAN that the server which provided a certain service (for example the email) has changed IP and therefore they must reconfigure their clients. Reboot the new VM and check that everything is working. This procedure should work with all the other GNU Linux OSs, probably with BSD too, with some change. Enjoy your new shining virtual machine!   Credit for this solution to: https://linuxadmin.io/hot-clone-linux-server/
Post n°65 pubblicato il 28 Gennaio 2020 da taichung
Recentemente mi è capitato di dover cambiare tutti i link di un certo sito, precedentemente scritti nei miei vari post. In pratica tutti i miei articoli o quasi contenevano all'interno un link del tipo http://xyz.com che dovevo modificare in https://abcxyz.com. Prima fatevi una copia del database, in caso qualcosa dovesse andare storto!! Utilizzando phpmyadmin o la console di mysql/mariadb, ho utilizzato se seguenti query: UPDATE field_data_body SET body_value = REPLACE( body_value, 'http://xyz.com/','https://abcxyz/'); UPDATE field_revision_body SET body_value = REPLACE( body_value, 'http://xyz.com/','https://abcxyz/'); Si tratta delle due tabelle che contengono il corpo dei post, nel campo body_value. Nelle query prima si inserisce la vacchia stringa di testo, e poi quella nuova. Terminata l'operazione, accedete al vostro sito come amministratore e svuotate la cache. Poi disconnettetevi e pulite anche la cheche del browser. Se tutto è andato bene, e lo potete verificare con gli strumenti di sviluppo del browser, i link sono stati tutti cambiati
Source: https://drupal.stackexchange.com/questions/83028/how-can-i-replace-all-my-internal-links-automatically
Post n°64 pubblicato il 08 Luglio 2019 da taichung
I want to let the ldap user foo login in my Mageia 7 computer. The working Ldap server is in another Linux box. Usually you can make use of the utility drakconf in MCC to change the way a user authenticates in a Mageia pc. Unfortunately there's an old bug which hasn't been solved yet (I remember I had that when I migrated from Mageia 5 to Mageia 6). Well not everything is lost. First at all follow the usual procedure to make use of Ldap through drakconf: in this way all the needed packages will be installed. You can also try to configure the authentication with Ldap, but you will see that probably it doesn't work. Well, we need to edit the file /etc/openldap/ldap.conf and write down the parameters BASE and URI (the IP of your Ldap server) according to your server. Something like that: BASE dc=example,dc=com URI ldap://192.168.1.1:389 If you don''t make use of encryption through SSL certificates, leave everything else as it is. the command "ldapsearch -x" and "getent passwd foo", where foo is the name of an user in our example, will let you know if the Mageia pc is able to contact the Ldap server in the other computer Next, the most important file: /etc/pam.d/system-auth First at all, make a copy of it. BEWARE: in case of errors, you'll find yourself locked out your pc: follow my instructions at your own risk. In the worst case you'll need to reinstall the operating system, if you aren't able to use a live distribution to correct the errors. Drakconf isn't able for unknown reasons to change the content of /etc/pam.d/system-auth, therefore we need to edit it, by adding the following lines where appropriate: auth sufficient pam_ldap.so use_first_pass DO NOT COPY AND PASTE THIS AS IT IS!! You must copy the first line among the other lines beginning with the word "auth", the second line among the other lines beginning with the word "accont", and so on. NOTE: the above lines must be written in the respective section of the file, before pam_deny.so, and after pam_unix.so. For example, for the key "auth", it should look like: auth [success=3 default=ignore] pam_unix.so nullok_secure You can now open a TTY and try to login with the LDAP user. If you still can't login, re-read carefuly the instruction and retry. It can also be that you have omitted installing a needed package (nsswitch? nslcd?...) I really hope Mageia can fix this long time annoying and blocking bug very soon, we have already waited for a too long time. If you want, you can fill a bug report on the Bugzilla of Mageia: https://bugs.mageia.org/describecomponents.cgi?product=Mageia
Post n°63 pubblicato il 05 Maggio 2019 da taichung
To install a plymouth theme, you can use apt to get one of those ugly themes in the repository, or download it for example from gnomelook.org. Then you need to unpack it in /usr/share/plymouth/themes as root. For example, we've downloaded a theme called "solar". We need to let the system know that this theme is available and we want to use it as default. I won't explain the meaning of all the commands we need, you can look in Internet by yourself. As super user (or root) type in a terminal window: $ sudo update-alternatives --install /usr/share/plymouth/themes/default.plymouth default.plymouth /usr/share/plymouth/themes/solar/solar.plymouth 100 Then: $ sudo update-alternatives --config default.plymouth Here you must chose the theme you want (solar in our case) Last: $ sudo update-initramfs -u That's it.
Post n°62 pubblicato il 20 Maggio 2018 da taichung
Può essere utile avere la lista dei pacchetti installati su di una macchina, per esempio se si deve realizzare un'installazione identica da un'altra parte. Per avere la lista dei pacchetti in un file: #dpkg --get-selections | grep -v deinstall > elencopacchetti.txt Poi si copia tale file sull'altra macchina. Su quest'ultima si danno, come root, i comandi: #dpkg --set-selections < elencopacchetti.txt #dselect Dall'interfaccia testuale di dselect (che ovviamente deve essere installato prima se non presente), si seleziona la voce Aggiorna pacchetti selezionati Va da sè che i repository devono essere gli stessi sulle due macchine, così come ovviamente la versione del sistema operativo.
|
||||||||||||
|
|
Condividi e segnala 
Inviato da: cassetta2
il 23/08/2019 alle 12:59