sylver_dragon

The first issue with running a coin miner is using company resources for your own profit. Your own system, using your own electricity, go for it. Running it on a company owned laptop, while at a company building, burning electricity the company is paying for. Ya, that starts to get uncomfortably close to fraud or theft. There is also that whole, “running unauthorized software on a company system, doing who knows what else in the background.” There is a very real possibility that the coin miner has unknown vulnerabilities which could allow remote code execution; or, just outright be malicious and contain a remote access trojan. Maybe he was smart enough to audit all the code it was using and be very sure that’s not the case. More likely, he just grabbed a random implementation of XMRIG, put his wallet in the config file and ran it. Either way, he also made a point of refusing to remove it, so we escalated up to management. With the recent ransomware outbreak having been in the multi-million dollar (possibly low tens of millions) damage range, refusing to remove unauthorized software went over about as well as a lead balloon. There may have been other factors at play; but, the unauthorized software and being a dick about removing it was what got him out the door.

If you spin it up, fucking own it. When you’re done with it, shut it down. I have long lost count of the number of times I’ve reached out to a team to ask about the coin miner they are running on some random EC2 instance only to find out that some jackass spun it up for a test, gave it a public IP, set the VPC to allow any inbound traffic, installed all kinds of random crap and then never updated it. Nor did it get shutdown when the test ended. So, a year and a half later, when the software was woefully out of date, someone hacked it and spun up a coin miner. Oh, and the jackass who set it up didn’t bother to enable logging or security monitoring. But, they sure as hell needed the ability to spin stuff up on their own. Because working with IT to get it done right would be too hard for their fragile little ego.

You joke, but I’ve actually been responsible for a coder getting shown the door for running a coin miner on his work laptop.

In his defense, cyber security at that company was crap for a long time. After a ransomware outbreak, they started paying attention and brought some folks like myself in to start digging out. This guy missed the easy out of, “hey that’s not mine!” The logs we had were spotty enough that we would have just nuked the laptop and moved on. But no, he had to fight us and insist that he should be allowed to run a coin miner on his work laptop. Management was not amused.

The short answer is, it’s what we were taught in school. Like many preferences, it’s shaped by the culture we grow up and live in.

I’m sorry but it doesn’t make sense to me.

Of course not, you were raised and live in a different culture; so, your preferences are different.

Ultimately, the right answer is ISO8601. It’s unambiguous and sorts well on computers. But, I don’t think any culture is teaching that as the primary way to write dates, so we’re stuck with the crappy ways.

No, if you open a terminal and run:
sudo dmesg

You should get a long output which is the kernel log. Assuming the crash happened recently, there may be something in the last few lines (bottom of the output) which could indicate why the process died (or was killed). Keep in mind that this is a running log; so, if it’s been a while since the crash, the entries for it may be higher up in the log. It’s often best (if you can) to trigger the problem then immediately go run the sudo dmesg command and look at the output. With luck, there will be useful logs. If not, you may need to look elsewhere.

On my system (Arch), if I have too much running, the kernel can kill processes based on resource starvation. It’s quite possible you’re running into a similar limitation. There should be a message in dmesg when this happens.

NextCloud - Stop storing your data on someone else’s computer. Works well to allow syncing KeePass databases between devices.

The person who authored the cheat(s) the other person is using. Because clearly, if I lost they must be cheating. /s

For many games, I’d argue that you are to blame for your loss. Assuming the game is based purely on skill, then your ability to execute said skills is the only factor which matters. Consider something like Chess, where the game is solved and one’s ability to win is really down to your ability to memorize board positions and recognize the optimal move. If you lose, it’s likely because you failed to pick the optimal path.

This is mitigated, to a greater or lesser extent in games where chance plays some role. It’s entirely possible to chose an optimal path, but have RNGesus decide that you get to lose today. Some games provide some ability to manage the risks created by randomness, but you often have some reliance on “luck”. Obviously, the more luck dependent a game is, the less control you have over winning/losing.

And then there is the issue of other players who can affect the outcome. If you play a game where there are more than two players, the other players may be able to change the course of the game enough that, no matter how well optimized your choices, you cannot win. This leads to the classic “kingmaker” problem in board games. It may be that someone who is themselves unable to win is in a position to directly effect the outcome of the game in such a way as to make another player win or lose. So, maybe you played a very good game, but the kingmaker decides that you lose.

Ultimately, the answer to the original question is, “it depends”. And there are a lot of factors one must look at to come to an answer. And that answer is unlikely to be whole one thing or the other.

Docker is just going to be used to run the applications which host your website. What you need to decide first is what your website will be and that will inform the decision on what technologies will be used to host your website. For example, if you are thinking of something like a blog, you might choose WordPress as the main hosting platform. This will need some sort of database behind it, for which you might choose MySQL or Postgres. You would also need some sort of web server software, which you might choose Nginx or Apache. At a basic level, you could now have the entire web stack defined: E.g. WordPress, MySQL, Nginx.

Ok, so now you need to sort out where those technologies will run. The easy, older solution is to spin up a physical box and load all of the software packages on the native Operating System (OS) of that box. This works perfectly well, until it’s time to start patching and updating the OS and software. And you will want to do those updates. This will probably go well for the first few upgrades, but eventually something will go sideways. Often this will be that several of your software packages will require different version of the same, underlying library. Or, something will just not install right and your website stops working. This is where docker comes in.

Docker lets you run each software package in it’s own contained environment. Each application runs in it’s own container, and the other containers are only reached via network calls. It’s like having a separate virtual machine for each service (this is how we used to actually run stuff like this); but, without all the overhead of actually having multiple virtual machines. So, even if you upgrade package XYZ in the Nginx container to version 2.1, the MySQL container could have package XYZ still running at version 1.9. Neither container knows or cares about what is running in the other containers.

The other advantage of containers is that the base OS and software in the container is usually well defined and doesn’t change much. The container will be able to reach permanent storage for any configuration and data files. But, if something goes wrong with the OS or software inside the container, then that container is destroyed and a new copy spun up and attached to the config/data storage. Software upgrades can also take advantage of this, as you can often stop the current container and start a container running the new version of the software, attach it to the config/data storage and maybe run some sort of “upgrade database” command. This makes for less mistakes and chances for things to not go well.

If your goal is to learn to self host, I would recommend putting those posts over in the !selfhosting@slrpnk.net. They are likely to get a better reception than in the programming and Linux communities you spammed with this post. Though, even there you may run into a bit of the RTFM! vibe you got here if you are posting questions without context and which appear to be low effort “I want to do something but have made no attempt to learn anything on my own”. I’d recommend spending some time reading long form blogs/guides on web hosting and watching YouTube videos. Again, long form stuff. Skip the clik-bait-y crap with titles like “get your website running in 5 minutes! <insert stupid emojis here>”. You’ll want to learn the basics on Docker and what is required to run and host a web site. Once you are able to get containers going, try setting up a web stack on your local system (don’t go paying for anything yet) and see if you can get it working and understand how it works. You’re almost certainly going to screw it up a few times in the process, that’s ok. That’s another great feature of containers, you can bork them up really, really bad and not have to care. You delete the container, maybe wipe the attached storage and try again.

Good luck.

It’s a matter of circumstance. Authoritarianism is only useful in situations where time pressures make the slow, deliberate decisions of democracy unworkable. Combat is a good example of this. When the shells are raining down around you, there isn’t really time to hold a vote on how to proceed. So, in such situations there is usually a chain of command which is given authoritarian control. Other emergent situations will also often require similar levels of top-down control. The person in charge may not make the best or fairest decisions in the heat of the moment. But, inaction will almost certainly be a worse choice.

The other side of this is, when the situation isn’t emergent, a democratic (well, really semi-democratic, but I’m going to use “democratic”) system is likely the best choice. And those democratic systems would be wise to prepare for the emergent situations by identifying and designating the people who will be handed dictatorial control when the fecal matter hits the air circulator. And the system for identifying when the emergency has ended, how dictatorial power is unwound and how the performance of the person handed that power is to be judged.

The reason I hedged with “semi-democratic” is that a truly democratic system can have issues too. The classic “tyranny of the majority” problem. As any majority could override the rights of a minority in a truly horrible fashion. The solution being things like constitutional democracies, where the power of the majority is limited in specific ways (e.g. unrevokable rights).

No, but the country has problems. It’s always had problems. Even with all of the economic hardship and political strife we have today, most people are safer, healthier and have better prospects today than they have had in most of US history. It’s by no means perfect and we have a lot of work to do. But, giving up and checking out has never improved anything. It also doesn’t help that we have a steady drip-drip-drip of negative information fed to us by our phones and algorithms. We are also facing one of the largest Constitutional Crises in US History, with the President pushing the boundaries of his Constitutional powers. Even if nothing breaks, we are likely to see many changes from all this. Hopefully, those changes result in better guardrails on the Presidency. And maybe even a repudiation of the Roberts Supreme Court. But, such a future is hard to see when we are in the middle of the storm.

I even have hope for the slight voting majority which put Trump back in power. It’s easy to dismiss those folks as a bunch of <insert invective terms here>. And some of them almost certainly fit those descriptions. However, there are a lot of them which are just scared and confused by the FUD sandwich being fed to them by the 24-hour news cycle, social media algorithms and politicians looking for easy votes. It’s going to be hard work to pull them back off the brink. And if you’re not up to that work, I understand. It’s hard to want to put in the effort for folks who seem so far gone. I’ve spent a lot of hours arguing with folks with whom I disagree wholeheartedly. It’s tiring and I can only take so much before I decide it’s time to move on for a while. But, I would rather keep up the argument than let the country slide into full blown autocracy.

So ya, I have hope. It’s a grim hope and one which recognizes that we could lose. But, giving up now feels premature.

When people stop believing that justice is possible via the government system, they will seek it through other means. It doesn’t make it right, but it does provide a warning that the system is failing.

Any sufficiently advanced technology would be indistinguishable from magic.

That depends on the use case. For drive encryption, a centrally assigned and managed password is fine. It provides for protection of data at rest while also ensuring that a single point of failure (the user) won’t remove access to the data contained on the encrypted volume. Since it’s not intended to prove identity, that risk needs to be mitigated by a different control.

At most organizations I have worked at (both IT and cybersecurity), decryption keys will be centrally managed. With some technologies (e.g. Bitlocker), it’s possible to have multiple passwords which can be used to decrypt the drive, and it could be possible for the user to have one only they know. However, there isn’t a logging mechanism to verify which password was used to unlock the drive, leaving the issue of non-repudiation. This could probably be fixed by having some sort of system which logs which user unlocked the drive, but that would be a very hard thing to do securely. Any such log would need to be in a space the bootloader can reach and write to, and now that location needs to be secured in a way which prevents a malicious actor from modifying the log. At that point, we’re quickly arriving at having TPM and we might as well go whole hog and just do TPM and secure boot. Which is a great bit of technology; but, now only proves that the system hasn’t been tampered with.

As a tangent, the reason most organizations centrally manage drive encryption keys is the need to unlock the drive, in the event the user is no longer able to. If you win the lottery, turn your laptop in and run off to parts unknown, the organization may want to unlock the laptop to recover anything you were working on. So, they need access to the decryption key.

Ultimately the problem is that the encryption password and your user account password are solving different security problems and there isn’t a lot of good overlap between the two.

I have a 6 year old phone which gets charged overnight as I sleep. It still makes it though the day. What the heck are you running which is chewing up your battery so badly?

If the device is encrypted and single-user there is no good reason to require further login after the first.

The reason is non-repudation. Ignoring the fact that the drive’s encryption should have been handled by TPM and not be bothering the user, the drive encryption password does not establish who is using the laptop, only that they know the unlock password. Unfortunately, those unlock password are usually centrally assigned and managed, which means that they are not something that only the user knows. Also, it doesn’t have a good second factor. If the laptop is stolen, there is nothing keeping an attacker out, if they know the password. Their account, on the other hand, should have a password only the user knows. Yes, central IT can reset the password, but this creates logs which show the reset and can be used to prove that the password was reset, and who reset it. And the user’s password can be backed up with a second factor. So, a stolen laptop isn’t an easy on-ramp to the organization’s network.

As for logins after that, it gets harder to justify. OS, email and most web portal logins should be handled via SSO. For most users, this should mean that their drive gets decrypted via TPM, they type their password into the OS login prompt, deal with 2FA and that’s it. For users with admin access to stuff, there will be a separate login step when they need to elevate permissions, but that should largely be limited to IT staff and developers. For the original poster, it sounds like their organization’s IT is being run on a shoestring by someone who either doesn’t know or isn’t allowed to do it well.

I’ve not returned an item over it, but I’ve often wondered if there was a market for a company which de-LEDs items.

As in most social media apps, downvote and move on. Personally, I have a list of channels I subscribe to and mostly just stick to watching the content they produce. None of that is reaction videos, which I agree are lazy and stupid, but I guess some people like them or they wouldn’t keep making the rounds.

I just want to stop feeling imposter syndrome. I’m nearing 50, at work everyone seems to think I am one of the most competent people they have met in my field. I get the hard problems, get dragged into lots of projects as a technical consultant. And yet internally, I forever feel like I’m “faking it until I make it”. Like I’m one question away from being unmasked as a kid playing at knowing what I am doing. Consciously, I know I am not and that I’m actually pretty good at this. But, every time I get a meeting request from my boss, I still get a moment of panic thinking, “this is it, I’m about to be fired”. That’s what I want from “growing up”, to just not feel that feeling constantly.

Also, I want to be independently wealthy when I grow up. Fuck this whole work thing.