Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The day I locked everyone out of the company intranet

dancowell.com

Post reply on HN
Print view View original

111–120 of 130 posts

Re: The day I locked everyone out of the company intranet

#111

Post by Lvl999Noob »

loa_in_ wrote: post #95
reaperducer wrote: post #75

Earlier quoted context omitted.

My chooosen database explorer is Dbeaver I just checked it out, and it looks promising. Con: There are too many licensing options. I'm not even sure which one I would need. Pro: They'll send out an invoice, like a real company. I work for a billion-dollar healthcare company, and if your company only takes PayPal, or Venmo, or something else that makes it look like two guys in a basement, it'll never get through our p…

As if two guys in a basement couldn't send out an invoice

The parent isn't saying that they couldn't. They are saying that they shouldn't advertise their two-guy-ness in the financial parts of their company.

Re: The day I locked everyone out of the company intranet

#112

Post by KennyBlanken »

stevezsa8 wrote: post #43
fukawi2 wrote: post #26

Earlier quoted context omitted.

No, I did the entire table. That helped me find corner cases and errors in my logic having such a bigger range of source data.

Maybe I don't fully comprehend what you're saying... but is it even possible to do this? I mean what if at some point particular entries were manually tweaked and the database was updated to fix an error in an invoice or something. And then you recreated data from what you assume is 100% reliable data. I'm happy to try to understand if you don't mind simplifying the explanation.

Probably compared their code's recreated table against the table from the day old backup.

If twenty years worth of data (up until two days ago) match, then the recreation of the missing day is probably fine too. It's not guaranteed of course, but...

Re: The day I locked everyone out of the company intranet

#113

Post by menacingly »

gumballindie wrote: post #66
menacingly wrote: post #63

Earlier quoted context omitted.

In most of my scenarios, I'd actually rather cause a catastrophic global change than a silent subtle corruption of a handful of rows

That may be fun in a trivial setup such as op’s but when millions of customers or billions of transactions are affected it’s a nightmare. A competent engineer runs queries against a local and then a uat db, verifies results and then on prod. But if you must do it in prod then it must be limited in scope.

We're on the same page with the best approach, I just don't consider corrupting an unpredictable subset of my database much of an improvement. It's not closer to correct, it's just still incorrect.

Re: The day I locked everyone out of the company intranet

#114

Post by limaoscarjuliet »

IronWolve wrote: post #82

My first sysadmin job at a call center, the call center reps use the same directory for all the users. And, I'm working tickets to delete old users accounts... The old grey haired sysadmin backs up the directory so he can instantly restore it. Seems this happens all the time. Whew.

When you really mess up a call center, it is called a gopher event - entire floor having lost their audio suddenly stands up in their cubicles and looks around. Been there, caused that.

Re: The day I locked everyone out of the company intranet

#115

Post by somat »

matsemann wrote: post #27

I wish a DELETE or UPDATE only affected a single row by default (and perhaps even wouldn't commit if it would hit multiple rows), unless a keyword for MANY or something similar was added. Aka DELETE ALL where x == y or DELETE MANY where x == y or perhaps you need an explicit limit for it to not be 1, so DELETE where x == y LIMIT ALL

The way a DELETE without a WHERE clause gets the whole table makes sense conceptually but it always gives me the creepy crawlies when typing the statement. While I normally dislike superfluous syntax I would welcome changing the sql grammar to enforce a where clause on delete, that is, to delete all rows in a table would require "delete from table where true;"

Re: The day I locked everyone out of the company intranet

#116

Post by fukawi2 »

stevezsa8 wrote: post #43
fukawi2 wrote: post #26

Earlier quoted context omitted.

No, I did the entire table. That helped me find corner cases and errors in my logic having such a bigger range of source data.

Maybe I don't fully comprehend what you're saying... but is it even possible to do this? I mean what if at some point particular entries were manually tweaked and the database was updated to fix an error in an invoice or something. And then you recreated data from what you assume is 100% reliable data. I'm happy to try to understand if you don't mind simplifying the explanation.

I can't remember the specific details now (almost 20 years have passed!), but the STKM table was effectively a performance/convenience data store. Every bit of information was available from other transactional data, but in order to actually have a chronological historical view of "stock movements", it was maintained in this central table.

Re: The day I locked everyone out of the company intranet

#117

Post by fukawi2 »

cvoss wrote: post #71
fukawi2 wrote: post #12

I was working on an old old old "ERP" system written in D3 PICK. It's a database, programming language and OS all in one with roots in tracking military helicopter parts in the 1960's. I was working on it in the mid-2000s. It had SQL like syntax for manipulating data, but it was interactive. So you would SELECT the rows from the table that you wanted, then those rows would be part of your state. You would then do UPD…

> if your SELECT matched no rows, the state would be empty > UPDATE and DELETE are perfectly valid actions even without a state Some may call this a fun quirk :) but I'd call it a horrible mistake in the design of the system! It should have been conceptually obvious to the designer that an empty set of rows is a perfectly valid state and is fundamentally different from "no state".

You're probably right, but back then it was assumed you knew what you were doing I guess. The old idiom of "Linux won't stop you shooting yourself in the foot" was even more true of this system.

Re: The day I locked everyone out of the company intranet

#118

Post by KronisLV »

philderbeast wrote: post #74

"All of your colleagues have done something dumb. Don't be afraid to tell us when you make a mistake. We all remember our first screw up and will be happy to help." Never have truer words been spoken. As I tell all the new juniors at work doing sysadmin type tasks, everyone has deleted the production database at least once. Mistakes will always happen, it's how you deal with them that defines how good you are at the…

> Don't be afraid to tell us when you make a mistake. We all remember our first screw up and will be happy to help.

This is very much dependent on the circumstances - sometimes people won't be supportive or encouraging, but cold at best and toxic (rude, making fun of mistakes, letting their egos run wild) at worst. This is more likely to happen in some work cultures/companies than others, and there can also be individuals that are allowed to persist with their problematic conduct in otherwise okay environments.

If you are ever in such environments, acknowledge the fact, possibly push back against stuff like that and definitely be on the lookout for alternatives, where you'd be able to prosper.

Thankfully, my personal experiences have mostly been okay, but I've definitely seen both attitudes and choices that can make everyone's lives worse, to the point where I wrote the satirical article "The Unethical Developer's Guide to Personal Success": https://blog.kronis.dev/articles/the-unethical-developers-gu...

Re: The day I locked everyone out of the company intranet

#119

Post by hahamaster »

Decades ago my ex colleague was supposed to enter a command handwritten on a piece of paper saying "rm -rf /var/log/blah/" which she typed in as "rm -rf /var / log/blah / ". Everyone knows it's awesome to insert white space to increase legibility. It was a production database server.

Re: The day I locked everyone out of the company intranet

#120

Post by jorgesborges »

hahamaster wrote: post #119

Decades ago my ex colleague was supposed to enter a command handwritten on a piece of paper saying "rm -rf /var/log/blah/ " which she typed in as "rm -rf /var / log/blah / ". Everyone knows it's awesome to insert white space to increase legibility. It was a production database server.

That’s an insane command to pass to an untrained person on a piece of paper to type into the terminal of a production server.
Post reply on HN