So... one of my servers is completely refusing logins. Even the out-of-band console is not usable - the system gives me a "login incorrect" error without letting me enter a password. What gives?
Currently in rescue mode.
(openSUSE Tumbleweed - this is my experimental cloud desktop server)
Hmm... the audit log contains a smoking gun: the program responsible for handling the login somehow changed to /usr/bin/xdm, which obviously fails when there's no X server running.
Some documentations, blogs and forums and other examples on the web use pam_unix2 in /etc/pam.d/ configurations. An example taken from pam_winbind manpage:
auth required pam_env.so
auth sufficient pam_unix2.so
auth required pam_winbind.so use_first_pass
accoun...
Looks like the PAM configuration was outdated. Ran pam-config --create.
(pam-config is SUSE-specific)
Generating a new PAM configuration should fix it.
See, this is why I like openSUSE. They have these tools that automate doing these sorts of configuration tasks.
Problem solved.
Sometimes, openSUSE Tumbleweed breaks in weird ways like this (e.g. I've had networking issues in the past when they switched to predictable network interface names), but as a whole, openSUSE is a fantastic distro. It's that a rolling release tends to be less server-oriented and less reliable than the regular Leap release.
Again, this is an experimental cloud desktop server for my personal use and doesn't provide any public services, so some downtime is acceptable.
Managed to short one of the motherboard USB ports. Astaroth powered down immediately at the power supply level. It looks like all ports are working normally.
Well, was trying to plug in a Type-C port into the (sole) Type-C port on the motherboard, somehow put it into a Type-A port. Looks like a VBUS to ground short, which is why it turned off immediately.
See, this is why a good PSU is worth every dollar.
some people just have one key. some people do high-security and low-security keys, e.g. the latter might go on a laptop.
some people have a different key for every machine
as you go up the tree, it's harder to manage but more secure (you'd need to have some way to add the new key to existing deployments but it's easier to remove compromised keys)
@MichaelFrank You don't really need to. Unlike a password, it's virtually impossible to crack public-key authentication (at least with current technology).
@Bob Technically, the supply is capable of outputting 20A on the +5V rail, so I'm not sure how Seasonic engineered this to catch a short so quickly, before any hardware damage occurred.
@Bob Unlikely, the voltage dropped some 0.25V on a 2.5A load. The impedance is just too high for it to have passed 20A without damaging something. Nearly all of the power would have been heat.
There's no way the motherboard would have survived a 140W dead short (and possibly more as OCP does take a few milliseconds to respond) with no detectable damage.
...gave it some thought. If we talk about the voltage drop...
> the voltage dropped some 0.25V on a 2.5A load
That's 0.1 ohms, which means you have a prospective short-circuit current of 50A.
Hence, the 28A overload protection limit may have been reached.
Again, though, I doubt we actually had anywhere near 28A of current, nor was a short-circuit present for long enough to cause any damage. I'm pretty sure this was motherboard protection.
I'm going to be keeping a close eye on the USB subsystem. I don't suspect any lasting damage occurred (and high-end ASUS boards are designed to be resistant to this sort of fault) but I don't know what might happen in the long haul. At least all the ports pass all the tests I could perform, including USB 2.0, USB 3.0 (with data transfers confirming SuperSpeed operation), and electrical load testing up to 2.5A.
downside to being off, i have to put up with my annoying neighbours, them leaving the fire escape open and their questionable recreational inhalation habit
actually, it is funny this should happen now. I live in India, and there is this mobile carrier called Jio. So I install a server onto my android device and run it, and I can access the localhost on my browser. Great, I thought. But then, I took a friend's phone and typed in the IP address of my phone onto the browser, and yeah, the same webpage opened up. But I took another guy's phone who uses a different connection and tried accessing the same webpage with the same IP
it doesnt open
i don't know if this is a thing with my carrier only(probably not)
Inspired by the comments to this answer and its question. Some of my local ISPs are using carrier grade nat, and as someone who occasionally runs his own servers, remote support, it would be highly useful to be able to work out if I, or someone I am trying to help is behind one of these.
How wou...
the taskbar on my windows, which has been set to automatically hide but appear as soon as my mouse cursor is on it, that same taskbar is not appearing anymore and the program like Chrome kind of take precedence (e.g is in the main screen)
@PradyothShandilya It matters who opens the connection.
Your phone can open an outgoing connection towards an address elsewhere. Once that outgoing connection is established, bidirectional communication is allowed. But you have to send the first packet.
Incoming connections don't work because the first packet is not allowed through.
is a .onion website technically a regular website, but accessible using a tor browser only because the tor browser has access to the ip where the .onion website exists?
via the tor dns server(if that is the way it does it)?
Some documentations, blogs and forums and other examples on the web use pam_unix2 in /etc/pam.d/ configurations. An example taken from pam_winbind manpage:
auth required pam_env.so
auth sufficient pam_unix2.so
auth required pam_winbind.so use_first_pass
accoun...
