Re: [CentOS] Upgrade OpenSSH version to the latest stable version on CentOS Linux release 7.9.2009 (Core).
On 2020-11-30 21:48, Peter wrote: On 1/12/20 4:04 pm, Kaushal Shriyan wrote: I am running CentOS Linux release 7.9.2009 (Core). Is there a way to upgrade OpenSSH version openssh-7.4p1-21.el7.x86_64 to the latest stable version openssh-server 8.4 using yum repositories or rpm binaries? No, 7.4p1-21 is the most recent up to date version in CentOS 7. See https://access.redhat.com/security/updates/backporting/ for more info. hpn-ssh might be an option. https://sourceforge.net/projects/hpnssh/ My experience with it on CentOS and Ubuntu has been very good. Jack ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Upgrade OpenSSH version to the latest stable version on CentOS Linux release 7.9.2009 (Core).
On 1/12/20 4:04 pm, Kaushal Shriyan wrote: I am running CentOS Linux release 7.9.2009 (Core). Is there a way to upgrade OpenSSH version openssh-7.4p1-21.el7.x86_64 to the latest stable version openssh-server 8.4 using yum repositories or rpm binaries? No, 7.4p1-21 is the most recent up to date version in CentOS 7. See https://access.redhat.com/security/updates/backporting/ for more info. Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Upgrade OpenSSH version to the latest stable version on CentOS Linux release 7.9.2009 (Core).
Hi, I am running CentOS Linux release 7.9.2009 (Core). Is there a way to upgrade OpenSSH version openssh-7.4p1-21.el7.x86_64 to the latest stable version openssh-server 8.4 using yum repositories or rpm binaries? Best Regards, Kaushal ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Physical position of swap partition on the disk
On Mon, Nov 30, 2020 at 03:22:45PM +0100, Walter H. wrote: > is there a rule that says that the order of the partitions in the partition > table corresponds to the order of them itself on disk? > > no. > > keep in mind, that the order on disk can be something different then the > order in the partition table; No, but if my linux distro created out of order partition sequences on initial install I'd throw it in the trash. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Physical position of swap partition on the disk
On 30.11.2020 13:55, Jonathan Billings wrote: On Nov 30, 2020, at 02:35, Nicolas Kovacs wrote: * /dev/sda1: 500 MB /boot ext2 * /dev/sda2: 55 GB / ext4 * /dev/sda3: 4 GB swap Now, SSDs don’t have the same physical characteristics, so it doesn’t matter. Also, cloud storage and virtual machines don’t even have real hardware. without hardware neither cloud storage nor virtual machines; The partitioning is handled by different code starting in el7, and this seems to be the logic built in. I feel like it was written to assume that root and swap are on LVM. When it comes to resizing file systems, it might make sense to put the root ext4 at the end of the disk, so it is actually counterproductive to put swap at the end. is there a rule that says that the order of the partitions in the partition table corresponds to the order of them itself on disk? no. keep in mind, that the order on disk can be something different then the order in the partition table; Walter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Physical position of swap partition on the disk
On Nov 30, 2020, at 02:35, Nicolas Kovacs wrote: > > Yesterday while installing a fresh CentOS server, I wondered how big of a deal > the physical position of the swap partition on the disk is. > > Here's an example of a simple MBR partitioning scheme on a legacy BIOS machine > with a 60 GB SSD: > > * /dev/sda1: 500 MB /boot ext2 > * /dev/sda2: 4 GB swap > * /dev/sda3: 55 GB / ext4 > > In the old (Slackware) days, I created the partitions manually using fdisk. > > Now when I do something similar in Anaconda, I have to reason in terms of > mount > points. So in a similar order I create the /boot partition, the swap partition > and the root partition. > > What happens here is that Anaconda will always invert the root and swap > partitions and put the swap partition at the end of the disk. So my setup > looks > like this: > > * /dev/sda1: 500 MB /boot ext2 > * /dev/sda2: 55 GB / ext4 > * /dev/sda3: 4 GB swap > > I'd be curious to know what's the reason behind this, and if this kind of > configuration detail is really significant. When most of us had storage on rotational storage, the fastest, lowest latency access was close to the physical center of the disc, which corresponds to the start of the disk. You’d want swap to be highly responsive in case it was used for active processes. Now, SSDs don’t have the same physical characteristics, so it doesn’t matter. Also, cloud storage and virtual machines don’t even have real hardware. The partitioning is handled by different code starting in el7, and this seems to be the logic built in. I feel like it was written to assume that root and swap are on LVM. When it comes to resizing file systems, it might make sense to put the root ext4 at the end of the disk, so it is actually counterproductive to put swap at the end. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Table *** is marked as crashed and should be repaired
Hi, I've started migrating my sites to mariadb which is supposed to be a drop-in replacement of mysql. Both run on the same C6 box. DB folders were moved to a new location after both DB servers were stopped and properly upgraded. There were no reboots or power failures. Nevertheless I see these error messages in the logs: # cat /var/opt/rh/rh-mariadb102/log/mariadb/mariadb.log ... 2020-11-29 16:38:23 139882501732320 [Note] /opt/rh/rh-mariadb102/root/usr/libexec/mysqld: ready for connections. Version: '10.2.22-MariaDB' socket: '/var/opt/rh/rh-mariadb102/lib/mysql/mysql.sock' port: 3307 MariaDB Server 2020-11-29 16:38:23 139882394105600 [Warning] Access denied for user 'UNKNOWN_MYSQL_USER'@'localhost' (using password: NO) 2020-11-29 16:39:37 139882394105600 [ERROR] mysqld: Table './wordpress@002dstorefront/wp_wc_customer_lookup' is marked as crashed and should be repaired 2020-11-29 16:39:37 139882394105600 [ERROR] mysqld: Table 'wp_wc_customer_lookup' is marked as crashed and should be repaired 2020-11-29 16:39:37 139882394105600 [ERROR] mysqld: Table './wordpress@002dstorefront/wp_wc_customer_lookup' is marked as crashed and should be repaired 2020-11-29 16:39:37 139882394105600 [ERROR] mysqld: Table 'wp_wc_customer_lookup' is marked as crashed and should be repaired 2020-11-29 16:39:37 139882394105600 [Warning] Checking table: './wordpress@002dstorefront/wp_wc_customer_lookup' ... 2020-11-29 17:16:17 140059421116384 [Note] /opt/rh/rh-mariadb102/root/usr/libexec/mysqld: ready for connections. Version: '10.2.22-MariaDB' socket: '/var/opt/rh/rh-mariadb102/lib/mysql/mysql.sock' port: 3307 MariaDB Server 2020-11-29 17:16:18 140059356550912 [Warning] Access denied for user 'UNKNOWN_MYSQL_USER'@'localhost' (using password: NO) 2020-11-29 17:20:01 140059356550912 [ERROR] mysqld: Table './wordpress@002dstorefront/wp_options' is marked as crashed and should be repaired 2020-11-29 17:20:01 140059356550912 [ERROR] mysqld: Table 'wp_options' is marked as crashed and should be repaired 2020-11-29 17:20:01 140059356550912 [Warning] Checking table: './wordpress@002dstorefront/wp_options' 2020-11-29 17:20:02 140059356550912 [ERROR] mysqld: Table './wordpress@002dstorefront/wp_posts' is marked as crashed and should be repaired 2020-11-29 17:20:02 140059356550912 [ERROR] mysqld: Table 'wp_posts' is marked as crashed and should be repaired 2020-11-29 17:20:02 140059356550912 [Warning] Checking table: './wordpress@002dstorefront/wp_posts' 2020-11-29 17:20:02 140059356550912 [ERROR] mysqld: Table './wordpress@002dstorefront/wp_actionscheduler_claims' is marked as crashed and should be repaired 2020-11-29 17:20:02 140059356550912 [ERROR] mysqld: Table 'wp_actionscheduler_claims' is marked as crashed and should be repaired 2020-11-29 17:20:02 140059356550912 [Warning] Checking table: './wordpress@002dstorefront/wp_actionscheduler_claims' 2020-11-29 17:22:28 140059356550912 [ERROR] mysqld: Table './wordpress@002dstorefront/wp_usermeta' is marked as crashed and should be repaired 2020-11-29 17:22:28 140059356550912 [ERROR] mysqld: Table 'wp_usermeta' is marked as crashed and should be repaired 2020-11-29 17:22:28 140059356550912 [Warning] Checking table: './wordpress@002dstorefront/wp_usermeta' 2020-11-29 17:22:31 140059356550912 [ERROR] mysqld: Table './wordpress@002dstorefront/wp_woocommerce_sessions' is marked as crashed and should be repaired 2020-11-29 17:22:31 140059356550912 [ERROR] mysqld: Table 'wp_woocommerce_sessions' is marked as crashed and should be repaired 2020-11-29 17:22:31 140059356247808 [ERROR] mysqld: Table './wordpress@002dstorefront/wp_woocommerce_sessions' is marked as crashed and should be repaired 2020-11-29 17:22:31 140059356247808 [ERROR] mysqld: Table 'wp_woocommerce_sessions' is marked as crashed and should be repaired 2020-11-29 17:22:31 140059356550912 [Warning] Checking table: './wordpress@002dstorefront/wp_woocommerce_sessions' ... Note that after the crashed table was repaired mariadb reported multiple crashed tables in the same DB after restart. Any pointers? Never had such problems with mysqld. Is mariadb reliable and stable at all? # cat /etc/centos-release CentOS release 6.10 (Final) # rpm -qa '*maria*' rh-mariadb102-mariadb-server-utils-10.2.22-1.el6.x86_64 rh-mariadb102-mariadb-common-10.2.22-1.el6.x86_64 rh-mariadb102-mariadb-10.2.22-1.el6.x86_64 rh-mariadb102-mariadb-server-10.2.22-1.el6.x86_64 rh-mariadb102-mariadb-config-10.2.22-1.el6.x86_64 rh-mariadb102-mariadb-errmsg-10.2.22-1.el6.x86_64 rh-mariadb102-runtime-3.0-5.el6.x86_64 TIA, AK ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Reminder: CentOS 6 EOL on 30 November 2020
On 09/11/2020 14:24, Johnny Hughes wrote: > All, > > This is a friendly reminder. > > CentOS 6.10 will EOL at the end of November 2020. > > During the first week in December 2020, the 6.10 directory will move to > vault.centos.org > > Packages will still be available at: > > http://vault.centos.org/centos/6.10/ > > However, once moved, there will be no more updates pushed to > vault.centos.org. Therefore, security issues will no longer be fixed, > etc. > > You should take the rest of the month to either move to a newer versoin > of CentOS Linux ... or to procure Extended el6 support from Red Hat (EUS > RHEL 6). > > Thanks, > Johnny Hughes > As announced multiple times (on list[s], twitter, glog.centos.org and even https://c6eol.centos.org) , CentOs 6 is now EOL and so is being retired from mirror network. It's currently being moved to (capped and limited bandwidth) vault.centos.org and will be removed from mirror.centos.org (and so external mirrors in the next hours/days). mirrorlist.centos.org will also (like we do for all outdated/unmaintained and unsecured releases) start answering "invalid release" Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
