Posts made by NashBrydges

@NashBrydges Guess you can take a horse to water but you can't force him to drink.

@Pete-S The modules have all been reseated and swapped around to other slots and still the same thing. The same 6 slots remain unidentified (or unoccupied according to iDrac).

The CPUs are E5-2650 v1.

I've already had the conversation with the owner. Looks like we're going to keep things as they are since everything is operating normally (with the obvious missing RAM). We have good tested backups with another server to migrate the workload to in under an hour should something fail. He's unwilling to spend the cash on a new server and a deep diagnosis will be pretty pricy to pay for my time so...status quo for now.

@Pete-S That's what I also thought. I will have to spend some more time digging all the module numbers out tomorrow once I'm back there. There has to be something mismatched somewhere. Can't imagine anything else at this point.

@Danp I did, yeah, no quad rank dimms.

Here's a weird one. A new client with a Dell PE-R720XD SFF has 24 x 16GB sticks occupying every available slot in the server. As part of my inventory discovery work, I noticed that there are 6 slots that do not recognize the memory installed. Checked all modules and they are all the same Samsung ECC RDIMMs @ 16GB 1333Mhz memory so it isn't a compatibility thing. Spent a few hours moving modules around but appears as though the same slots are not recognizing memory regardless of which stick I have in there. It appears to be channel related because all unavailable slots are Processor 2 Channels 0 and 1...essentially 2 channels are not recognizing memory on that second processor.

The weird thing is that the server is running "perfectly". I add the quotes because while there are no errors and all VMs are working well with no degradation in performance, there is obviously an issue.

B1 = Processor 2 Channel 0
B2 = Processor 2 Channel 1
B5 = Processor 2 Channel 0
B6 = Processor 2 Channel 1
B9 = Processor 2 Channel 0
B10 = Processor 2 Channel 1

To make sure I wasn't missing anything, I checked the manual and for 2 processor setups, the memory currently installed should work properly. I've also reseated every single module just in case.

There are absolutely no log entries indicating any issues with memory going back over a year and the server has been rebooted a number of times since I've been looking at the memory issue.

I've also run the Dell diagnostics utility on boot-up and everything checked out ok with a PASS on everything.

Before I start dismantling the server to diagnose, any thoughts as to what to test next?

These are the troublesome slots.

@Pete-S No external access so they are golden. Password has been changed to a 20 character one as well.

@NashBrydges Yep, changed it to yes and now I can access via SSH!!! Thank you for the help!

@Pete-S Ah, I see that line is commented out. I suppose I need to change that to "yes" and uncomment?

Here is the full content...

cat /etc/ssh/ssh_config
#	$OpenBSD: ssh_config,v 1.35 2020/07/17 03:43:42 dtucker Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected]
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k
#
# This system is following system-wide crypto policy.
# To modify the crypto properties (Ciphers, MACs, ...), create a  *.conf
#  file under  /etc/ssh/ssh_config.d/  which will be automatically
# included below. For more information, see manual page for
#  update-crypto-policies(8)  and  ssh_config(5).
Include /etc/ssh/ssh_config.d/*.conf
> cat /etc/ssh/sshd_config
#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# To modify the system-wide sshd configuration, create a  *.conf  file under
#  /etc/ssh/sshd_config.d/  which will be automatically included below
Include /etc/ssh/sshd_config.d/*.conf

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile	.ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in Fedora and may cause several
# problems.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem	sftp	/usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

@NashBrydges
The 'include' location has a single file named '50-redhat.conf'

That files contains...

# The options here are in the "Match final block" to be applied as the last
# options and could be potentially overwritten by the user configuration
Match final all
	# Follow system-wide Crypto Policy, if defined:
	Include /etc/crypto-policies/back-ends/openssh.config

	GSSAPIAuthentication yes

# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
	ForwardX11Trusted yes

# Send locale-related environment variables
	SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
	SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
	SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
	SendEnv XMODIFIERS

# Uncomment this if you want to use .local domain
# Host *.local

@Pete-S

> cat /etc/ssh/ssh_config
#$OpenBSD: ssh_config,v 1.35 2020/07/17 03:43:42 dtucker Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected]
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k
#
# This system is following system-wide crypto policy.
# To modify the crypto properties (Ciphers, MACs, ...), create a  *.conf
#  file under  /etc/ssh/ssh_config.d/  which will be automatically
# included below. For more information, see manual page for
#  update-crypto-policies(8)  and  ssh_config(5).
Include /etc/ssh/ssh_config.d/*.conf

@Pete-S I can edit any of the files, just don't know where and what edits to make.

@Dashrender I thought that too but when I enumerate users...

cat /etc/passwd

I get this for root...

root:x:0:0:root:/root:/bin/bash

Unless I am reading this wrong, it doesn't look like that was the case. There are also no other users listed in the output besides the apache, mysql, systemd...etc.

I have a bit of a strange issue.

Random business owner called for help on their Nextcloud server. The previous IT guy set it up on Fedora and added Webmin. I was told that there was no new password selected for Webmin and that it would login as root so he gave me the access password and in fact I can login to Webmin using root + password however, when I try to login through SSH using the same credentials, I get an Access Denied error. I have verified the password over a dozen times and so far I am simply not able to login to SSH as root. No other users were setup.

I can issue commands through Webmin command shell except for the passwd command to reset root password so as of right now, I am locked out of SSH but Webmin works fine.

Any ideas as to why I am locked out of SSH? The error suggests a password issue but since the owner doesn't have any other password from the previous guy, I am grasping at straws so I don't have to blow it away and start from scratch.

I ran sudo pwck -r /etc/shadow and I get this output related to root user.

sudo pwck -r /etc/shadow
invalid password file entry
delete line 'root:$6$wMHG.3SSWjCcHHKO$9UmPtJcSyKaA/EKLWX6vhx02eaJH7yfdsDA9PRCadROMMb6Sgjggdq7V0/gNXB3q19LZK.sYshPiEyv3XYv8D.::0:99999:7:::'? No

@NashBrydges said in MeshCentral2 Failed To Renew SSL Cert:

Failed to obtain certificate: Error finalizing order :: signature algorithm not supported

One final update. After more searching, I found this that referenced the actual error I was seeing about algorithm not supported.

https://github.com/Ylianst/MeshCentral/issues/4676

After upgrading from v1.0 to v1.1 and rebooting, the cert automatically renewed and issue was resolved!

@EddieJennings

Next I checked status via letsdebug.net with the following results:

All OK!
OK
No issues were found with xxxxxxxx[dot]com. If you are having problems with creating an SSL certificate, please visit the Let's Encrypt Community forums and post a question there.

Still showing an expired cert. Is there a way to force renew the cert?

@EddieJennings

I also found this post from the MeshCentral author with a suggested tweak to the json file:

https://github.com/Ylianst/MeshCentral/issues/3245#issuecomment-982111380

@EddieJennings Here is the outcome (domain redacted):

node /opt/meshcentral/node_modules/meshcentral --debug cert

[root@ppmmeshcentral ~]# node /opt/meshcentral/node_modules/meshcentral --debug cert
MeshCentral HTTP redirection server running on port 80.
CERT: LE: Getting certs from local store (Production)
CERT: LE: Reading certificate files
CERT: LE: Setting LE cert for default domain.
MeshCentral v1.0.0, WAN mode.
MeshCentral Intel(R) AMT server running on xxxxxxxxx.com:4433.
Server customer1 has no users, next new account will be site administrator.
MeshCentral HTTPS server running on xxxxxxxx.com:443.
CERT: LE: Certificate has -4 day(s) left.
CERT: LE: Asking for new certificate because of expire time.
CERT: LE: Generating private key...
CERT: LE: Setting up ACME client...
CERT: LE: Creating certificate request...
CERT: LE: Requesting certificate from Let's Encrypt...
CERT: LE: Succesful response to challenge.
CERT: LE: Succesful response to challenge.
CERT: LE: Succesful response to challenge.
CERT: LE: Succesful response to challenge.
CERT: LE: Failed to obtain certificate: Error finalizing order :: signature algorithm not supported

Been running an internal MeshCentral2 server and noticed that it just failed to renew a SSL certificate that has been properly updating for nearly 2 yrs. It's running on Fedora 30 and was setup using this awesome tutorial...

https://www.mangolassi.it/topic/18767/install-meshcentral2-on-fedora-29-with-mongodb?_=1670279143289

I checked the letsencrypt log files but only entries are dated with today's date (cert expired Dec 2 so renewal was probably sometime before that)

sudo systemctl status meshcentral indicates MeshCentral is running and listening on port 443 properly with no errors indicated.

Everything I looked at appears to tell me it should be working but for some reason isn't renewing certs.

I have rebooted the server as well...just in case, to no avail.

Anyone have any suggestions for where to look next?

@michiganbb So you thought that necro-posting and whining about a 3yo post would be useful? Give it a try and see if that fixes your issue. You would have to do this anyway. Even if something works for one, doesn't mean there's a guarantee it works for you,. Backup the PC and try the changes. If they don't work...move on to something else.

There was NO resolution here. Client was one of those who was difficult getting payment from so we terminated the relationship before we did anything else.

Appears to require admin access in order to install so not sure how prevalent this could actually be.