Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Che Delilas
Nov 23, 2009
FREE TIBET WEED

KoRMaK posted:

I dont let my devs get prod passwords, and even I hate that i need to get in there sometimes. We have a well defined process to get data from prod to dev/test. It's saved my rear end and our rear end a bunch of times. I've also gotten dangerously close to running a rake command in prod (when I ment to do it in test) when I have test and prod ssh's open.

I habitually close out of prod as soon as I'm done running anything, and rarely leave it open for longer than I am typing.

I've altered our bashrc so that it screams .test at the command prompt now and that helps remind my dumbass a lot.

Dear IT Santa, all I want for Christmas is a DBA and also all my prod access to be taken away.

Hey you know what's great about Microsoft's SQL Server Management Studio? If you connect to an environment, open a query window in that environment, and then disconnect the object explorer from that environment, the query window you opened will still happily run queries on the environment that it was opened in in the first place! So you can easily, EASILY, connect to your local host or development environment, click over to the query window you still have open, and start loving around with production, and the only indication you're doing that other than potentially heart-stopping query results is a teeny-tiny little piece of text in the bottom-right (by default about as far away as it can get from the object explorer) that shows the server address the query window is going to run in. gently caress that was such a great UI design decision.

Like you, I always fully close any production environment connections I opened the instant I'm done. But that still doesn't feel like that's enough.

Hey, does anyone know off the top of their heads if you can change the color scheme of an SSMS query window based on what its open connection is? I feel like that'd be a great thing to Hotdog Stand.

Adbot
ADBOT LOVES YOU

Messyass
Dec 23, 2003

Holy poo poo yes that would be awesome

langurmonkey
Oct 29, 2011

Getting healthy by posting on the Internet

ChickenWing posted:

How do you lot decide what levels you log information at? I'm standardizing our server logs and finding it fairly difficult to come up with even a vague standard for what goes in error/warn/info/debug/trace, especially clarifying boundaries for the latter three.

So far I've settled on:

ERROR: soft/hard workflow failures. Something that was supposed to happen did not.
WARN: recoverable problems and indicators that something is wrong with external flows/internal data validity
INFO: basic "server is doing a thing", endpoint logging, SQL query logging, job health checks, aggregate stats
DEBUG: specific "server is doing a thing", specific stats, reporting non-exceptional exceptions
TRACE: method entry/exit, data dumps


obviously there's no One True Logging Standard, different strategies are applicable for different log consumers, etc - just looking for some wider feedback than the two people that provided input in my office

I would also be very careful about logging customer data. You can leak all sorts of personal stuff if you are not careful. Even error messages can have too much information to log - depending on the source of the error of course.

Hughlander
May 11, 2005

langurmonkey posted:

I would also be very careful about logging customer data. You can leak all sorts of personal stuff if you are not careful. Even error messages can have too much information to log - depending on the source of the error of course.

Thats a problem another team is going through at work right now. We are doing a massive GDPR rework of our ETL and its going as smooth as it could be, but we have a series of events on the client that is basically just a call stack of an exception in a raw JSON field. Apparently theres some percent of call stacks where the arguments / variables presented contain PII.

Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



Che Delilas posted:

Hey, does anyone know off the top of their heads if you can change the color scheme of an SSMS query window based on what its open connection is? I feel like that'd be a great thing to Hotdog Stand.

LinqPad does it right

B-Nasty
May 25, 2005

Che Delilas posted:

Hey, does anyone know off the top of their heads if you can change the color scheme of an SSMS query window based on what its open connection is? I feel like that'd be a great thing to Hotdog Stand.

At my last job, prod Sql Server wasn't exposed beyond production servers (as it shouldn't be), but there was an prod-level access VM that had Management Studio installed. The DBA had that SSMS install themed to an eye-searing black-on-red color scheme so he'd always know he was about to forget a WHERE clause in production.

MisterZimbu
Mar 13, 2006

Che Delilas posted:

Hey, does anyone know off the top of their heads if you can change the color scheme of an SSMS query window based on what its open connection is? I feel like that'd be a great thing to Hotdog Stand.

I did some poking around and found something like this.

If you bring up the Registered Servers panel, you can add a Server Registration; one of the options in the advanced options is to set a color for the server; this will change the toolbar color in the query editor when you're connected to that database.

edit: Apparently this option is in the "Connection Properties" tab too when you're connecting to a server.



There's also some plugins you can get that'll do similar stuff but most of them are paid.

We're bad people who host our test and prod databases on the same server, so ideally I'd like to be able to drive the color off the database name too (eg., Green if im on the dev server, Yellow if I'm on the prod server and the database name contains "Test", Red otherwise).

CPColin
Sep 9, 2003

Big ol' smile.

Che Delilas posted:

...The only indication you're doing that other than potentially heart-stopping query results is a teeny-tiny little piece of text in the bottom-right (by default about as far away as it can get from the object explorer) that shows the server address the query window is going to run in.

Holy poo poo I never noticed it was down there! Thanks for this. I've been trying to use the labels on the tabs to keep things in order, but the loving tabs are always the same width, no matter how many are open, and the database name is right in the middle, nicely obscured by the ellipsis. Like, who gives a poo poo what bogus filename you've given this window? And I know what my user name is! And why are you using an ellipsis when you could show the whole label? loving Microsoft.

Only registered members can see post attachments!

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

B-Nasty posted:

In Windows land, it's all Active Directory based. Apps shouldn't be using SQL auth to SQL Server, they should be using integrated auth. So, the app pool, Windows service, or scheduled task is run under a particular AD account that has login rights to SQL.

Beyond that, it's mostly your standard need-to-know/least-privilege type access control along with some kind of deployment tool (e.g. Octopus Deploy) that also allows fine-grain permissioning (e.g. devs can deploy to QA, but not PROD.) Another tool which is quite useful is something like Azure KeyVault, where secrets/encryption keys can be retrieved by the code at runtime (via HTTPS calls) instead of floating around in config files somewhere. One could have a DEV KeyVault instance that has dev/preprod secrets and one for PROD. The prod instance would be locked down via certificates only installed on PROD servers, which devs don't have access to.

As a developer, the stance really needs to be that I don't have, nor do I want to have, any access to/knowledge of production systems, prod AD account passwords, or prod-level secrets/keys. It slows things down and it requires IT support that is on-the-ball, but it's the right way to do things.

Thanks for that.

We unfortunately don't have development servers, just the prod network. I'm pushing really hard right now to just get some sort of automated source control into the workflow that, at the moment, is just making a copy of the file you're working on and putting some change comments in the header of the code (and no one actually does it).

I guess I'll look into setting up some service accounts for domain level authentication and something like KeyVault looks like it could be great. Our IT doesn't actually touch our production network which is its own nightmare, they just handed admin privileges to the prod network to some of the lead engineers years ago and never looked back. It's all quite a bit of a mess.

Mniot
May 22, 2003
Not the one you know
My favorite interactive SQL trick is to always run non-SELECT commands in a transaction. Never say
code:
UPDATE users SET banned = true;
when you can do
code:
BEGIN;
UPDATE users SET banned = true;
That way, when there's a heart-stopping pause before the server tells you it updated 2 million rows, you can just yank out the network cable like it's a bad Starcraft match.

B-Nasty
May 25, 2005

Portland Sucks posted:

Our IT doesn't actually touch our production network which is its own nightmare, they just handed admin privileges to the prod network to some of the lead engineers years ago and never looked back. It's all quite a bit of a mess.

Security best-practices are always a struggle, because human laziness and 'not-my-responsibility' are strong forces to overcome.

While I have many complaints about it, the PCI DSS (for handling credit card data https://pcicompliance.stanford.edu/sites/default/files/pci_dss_v3-2.pdf) is actually a really good starting point for companies that want to improve their process. Essentially, the checklist has common sense items on it like

* Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers)
* Limit access to system components [...] to only those individuals whose job requires such access
* Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers
* Development/test environments are separate from production environments with access control in place to enforce separation
* Change control procedures related to implementing security patches and software modifications are documented

Of course, the real value to something like PCI DSS is the fact that ultimately, someone has to sign their name at the bottom of the checklist. For the payment card industry, their enforcement in the event of a breach can be nasty. You better hope that you did your best to follow the guidelines if it's your name at the bottom of that document.

Che Delilas
Nov 23, 2009
FREE TIBET WEED

MisterZimbu posted:

I did some poking around and found something like this.

If you bring up the Registered Servers panel, you can add a Server Registration; one of the options in the advanced options is to set a color for the server; this will change the toolbar color in the query editor when you're connected to that database.

edit: Apparently this option is in the "Connection Properties" tab too when you're connecting to a server.

Thank you for this, set up my work machine just now and it's real nice having a more obvious warning sign.


Mniot posted:

My favorite interactive SQL trick is to always run non-SELECT commands in a transaction.

Handy. A former co-worker would always start his query writing with a /* when he was writing queries in prod, but the obvious downside to that is that you don't get the autocomplete. I like yours better.

Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



Mniot posted:

My favorite interactive SQL trick is to always run non-SELECT commands in a transaction. Never say
code:
UPDATE users SET banned = true;
when you can do
code:
BEGIN;
UPDATE users SET banned = true;
That way, when there's a heart-stopping pause before the server tells you it updated 2 million rows, you can just yank out the network cable like it's a bad Starcraft match.

Thanks for randomly locking tables in prod - I'm sure nobody will notice the downtime. Oh wait our SLA says what?!

MisterZimbu
Mar 13, 2006
One of the few things I actually like about MySQL is that it can be configured to prevent you from running updates and deletes without where clauses.

Munkeymon posted:

Thanks for randomly locking tables in prod - I'm sure nobody will notice the downtime. Oh wait our SLA says what?!

Oracle keeps everything in a transaction that locks tables by default as well, if I recall.

I remember working with a customer that had a really old, horrible DBMS called SqlBase backing one of their ERP systems.

Just opening up a connection to the database in their equivalent of SSMS would lock the entire thing.


Mniot
May 22, 2003
Not the one you know
Postgres does a pretty good job with locks, but yeah you can lock up the database pretty easily by being careless with a transaction. But I'd rather lose availability than data. And lol if you've got an SLA but your developers still have write access to the production database.

Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



Mniot posted:

Postgres does a pretty good job with locks, but yeah you can lock up the database pretty easily by being careless with a transaction. But I'd rather lose availability than data. And lol if you've got an SLA but your developers still have write access to the production database.

Devs sticking their grubby fingers into prod was what I thought the context around all of this was :shrug:

redleader
Aug 18, 2005

Engage according to operational parameters
It's fine. Just don't gently caress up on prod.

Here, you get full access to every production server and database from day 1. Few of our clients pay for pre-production environments, and we don't have a process for taking a prod DB and making it "safe" to work on. So you get people running up local websites connected to real DBs etc. Our docs remain neutral on the issue of "should I develop directly on the prod DB?"

We don't really do "best", or even "good" practice.

Mniot
May 22, 2003
Not the one you know

Munkeymon posted:

Devs sticking their grubby fingers into prod was what I thought the context around all of this was :shrug:

Sure. I'm saying if you have a SLA (and it's not some kind of joke SLA like "less than 10 business days downtime per year") that is a completely different ballgame.

My last job, we hosed around in the production database pretty frequently. We locked all the tables for three hours with a manual query once. Errors are always embarrassing and we learned from it, but it wasn't a big deal because we had no formal SLA and our users' expectations were basically that they'd be able to check their data at the beginning and end of the day.

On the development environment, where all developers were encouraged to play, we lost data a couple times from people running badly-written queries. Our product took streaming data, so you have to shut down the application to restore from backup and it turned out that Amazon RDS incremental backups can be really slow to restore.

lifg
Dec 4, 2000
<this tag left blank>
Muldoon

redleader posted:

It's fine. Just don't gently caress up on prod.

Here, you get full access to every production server and database from day 1. Few of our clients pay for pre-production environments, and we don't have a process for taking a prod DB and making it "safe" to work on. So you get people running up local websites connected to real DBs etc. Our docs remain neutral on the issue of "should I develop directly on the prod DB?"

We don't really do "best", or even "good" practice.

If programming was weight loss supplements, your company would be the Before picture.

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ

redleader posted:

It's fine. Just don't gently caress up on prod.

Here, you get full access to every production server and database from day 1. Few of our clients pay for pre-production environments, and we don't have a process for taking a prod DB and making it "safe" to work on. So you get people running up local websites connected to real DBs etc. Our docs remain neutral on the issue of "should I develop directly on the prod DB?"

We don't really do "best", or even "good" practice.

Same. We don't make customer stuff, but it's all one environment where I work. It's extremely stressful, but on the flip side people are used to the production environment just suddenly tanking so if you screw something up no one really cares all that much.

AskYourself
May 23, 2005
Donut is for Homer as Asking yourself is to ...
Yeah, I've had Prod access to DBs and VMs at my last three jobs. 2 out of 3 on day 1. 1 of them had prod credential in a wiki. They didn't care about security until a customer started complaining.

One eCommerce business at least kept the credit card transaction server access to a handful of senior that had passed security investigation, that was for PCI compliance.

It's pretty terrible really, if it was my company I wouldn't do it this way. As an employee I've always voiced my concerns about the lack of security and most of the time the company just doesn't care.

CPColin
Sep 9, 2003

Big ol' smile.
Just got a fun email, nested newest-to-oldest because Outlook:

My Supervisor posted:

Hey team, I need your help with a request that (Director) sent through (Manager). Please send me a high-level list of everything you did during fiscal year 2016 by 10:30 tomorrow. I need to get it to (Manager) by noon.

Manager posted:

Hey (My Supervisor) and (Other Supervisor), can you make a list of stuff your teams did during fiscal year 2016 by noon tomorrow? (Director) is asking for it.

Department Director posted:

Hey (Manager), can you send me a list of stuff your team has done in fiscal year 2016 by mid-day tomorrow? Thanks.

I like how it makes it look like nobody knows what the team did and how each email retells the story of the email it's quoting. I also like how I got here after the fiscal year ended, so I don't have to respond!

geeves
Sep 16, 2004

CPColin posted:

I like how it makes it look like nobody knows what the team did and how each email retells the story of the email it's quoting. I also like how I got here after the fiscal year ended, so I don't have to respond!

That's lovely thing for management to ask. And for 2016? Jesus.

Something like this was asked of us a few years back. We just sent them a Google Sheet of linked ticket numbers and titles by assignee from Jira.

They were not happy but we told them we didn't have time for this poo poo.

CPColin
Sep 9, 2003

Big ol' smile.
Apparently everybody was confused about what everybody else was asking for, because my supervisor just sent another email to tell everybody not to worry, because they're actually looking for some other statistic.

Holy poo poo, my previous post was only 2.5 hours ago? This afternoon is draaaaaging.

KoRMaK
Jul 31, 2012



CPColin posted:

Holy poo poo, my previous post was only 2.5 hours ago? This afternoon is draaaaaging.

I cleaned and restrung my office guitar for lunch and at the end of the day

went by too fast :unsmith:

csammis
Aug 26, 2003

Mental Institution

geeves posted:

That's lovely thing for management to ask. And for 2016? Jesus.

Something like this was asked of us a few years back. We just sent them a Google Sheet of linked ticket numbers and titles by assignee from Jira.

They were not happy but we told them we didn't have time for this poo poo.

CPColin posted:

Apparently everybody was confused about what everybody else was asking for, because my supervisor just sent another email to tell everybody not to worry, because they're actually looking for some other statistic.

This sort of thing happens pretty regularly (annually in fact :haw: ) at companies going for the R&D tax credit

lifg
Dec 4, 2000
<this tag left blank>
Muldoon

csammis posted:

This sort of thing happens pretty regularly (annually in fact :haw: ) at companies going for the R&D tax credit

That stupid tax is why I had to fill out time sheets while I was a full time employee at one job. They didnt care how long I worked, thank god, they just wanted to know what I was doing that could be counted as New Work.

I hate filling out time sheets.

Seat Safety Switch
May 27, 2008

MY RELIGION IS THE SMALL BLOCK V8 AND COMMANDMENTS ONE THROUGH TEN ARE NEVER LIFT.

Pillbug

lifg posted:

That stupid tax is why I had to fill out time sheets while I was a full time employee at one job. They didnt care how long I worked, thank god, they just wanted to know what I was doing that could be counted as New Work.

I hate filling out time sheets.

As an intern I used to dutifully take really good notes in a notebook. Guess who got asked to type up a report since he had such good records.

Now I just keep lovely notes.

Seat Safety Switch fucked around with this message at 18:07 on Nov 14, 2017

Hughlander
May 11, 2005

csammis posted:

This sort of thing happens pretty regularly (annually in fact :haw: ) at companies going for the R&D tax credit

As a manager I hate the R&D tax credit time. Because I take one for the team and sit down with the accountants for 4-5 hours going over the work done by the teams and how it can be considered undirected new work without guarantee of success.

DELETE CASCADE
Oct 25, 2017

i haven't washed my penis since i jerked it to a phtotograph of george w. bush in 2003
we have consultants who help us with the r&d tax credit stuff. all i had to do was go to a 30min meeting and tell them some details about the projects i worked on this year, they took notes and nodded and said "ok this is great thanks!" totally painless

CPColin
Sep 9, 2003

Big ol' smile.
(a few months ago)

Product Owner: "Hey, take this spreadsheet with Customer's priorities and get it into TFS."
Me: "Okay!" *creates a new TFS project and adds that stuff*
PO: "Great! I'll send it to Customer!"
Customer: "Whatever"

(a few weeks later)

Me: "Hey, it doesn't make sense for me to sit in on sprint planning if I have a separate backlog."
PO: "Okay, move all that stuff into the backlog the rest of the team uses."
Me: "Okay!"
PO: "We need a query we can run so Customer can see it."
Me: "Okay!"
Customer: "Whatever"

(just now)

Me: "Hey PO, none of Customer's tasks are fleshed out at all, hint hint."
PO: "Okay, let's all have a really long meeting."
Me: *runs the meeting, fleshes out the backlog, suggests formally taking over PO duty for Customer*
PO: "Wait, what's that thing at the top of the list?"
Me: "It's Customer's top priority. It has a different name because the one in the spreadsheet wasn't descriptive enough."
PO: "That's going to confuse them. Let's change all these backlog items into Features so we can show them less detailed info."
Me: "Whatever"

Now I get to create this backlog a third time! And my PO wants me to draft an email to get requirements from Customer and then have another meeting to review it!

Portland Sucks
Dec 21, 2004
༼ つ ◕_◕ ༽つ
You say Okay! a lot.

Edison was a dick
Apr 3, 2010

direct current :roboluv: only

Portland Sucks posted:

You say Okay! a lot.

It's code for "go gently caress yourself".

LLSix
Jan 20, 2010

The real power behind countless overlords

CPColin posted:

Now I get to create this backlog a third time! And my PO wants me to draft an email to get requirements from Customer and then have another meeting to review it!

Time to write a script.

Pixelboy
Sep 13, 2005

Now, I know what you're thinking...

Portland Sucks posted:

How should programmatic authentication for internal production systems typically look?

Azure AD + security groups. Works a charm

baquerd
Jul 2, 2007

by FactsAreUseless

CPColin posted:

Now I get to create this backlog a third time! And my PO wants me to draft an email to get requirements from Customer and then have another meeting to review it!

Tell them to get hosed, that's their job.

CPColin
Sep 9, 2003

Big ol' smile.

baquerd posted:

Tell them to get hosed, that's their job.

My PO is also my supervisor. I delicately pointed out, "Well, traditionally, the PO is the one who would collect these requirements." and she just laughed and shrugged. Whatever. I can list PO duties on my resume, now, I guess.

ChickenWing
Jul 22, 2010

:v:

I feel like your av is extremely relevant

Bruegels Fuckbooks
Sep 14, 2004

Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

ChickenWing posted:

I feel like your av is extremely relevant

He was in a movie that's way more appropriate for this situation

quote:

1st Bob: So you physically take the specs from the customer?
Tom: Well... No. My secretary does that... or they're faxed.
2nd Bob: So then you must physically bring them to the software people?
Tom: Well... No. ah sometimes.
1st Bob: What would you say you do here?
Tom: Look I already told you, I deal with the @#$% customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!

Adbot
ADBOT LOVES YOU

CPColin
Sep 9, 2003

Big ol' smile.

ChickenWing posted:

I feel like your av is extremely relevant

*"How To Save a Life" plays as all three of my backlogs die of rabies*

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply