|
CLAM DOWN posted:A noose. A noose would be well supported, will do its one designed function reliably, and is generally unacceptable to use in today's society. Printers are way more evil.
|
#
?
Sep 6, 2019 00:37
|
|
|
|
| # ? May 25, 2024 10:03 |
|
|
The Fool posted:Impromptu poll, choose the lesser evil:
|
|
#
?
Sep 6, 2019 00:48
|
|
|
Vulture Culture posted:In an AWS world, how are y'all reconciling a desire for least-privilege security access against the ad-hoc policy/role sprawl that creates? I don't think it should cause a ton of sprawl? You have a bunch of things that must grow, but they're decoupled and grow linearly so its not like you end up in a situation where you create a new internal team and you need 600 new individual inline policies or anything like that. The biggest trap I've seen people fall into is trying to make IAM be self service, relying on embedded SREs to manage it, or having it be a joint effort between an infrastructure team and a compliance team or something like that. Managing IAM at scale really needs context, and you need a single source of responsibility for it. After you have a (competent) single source of responsibility, ensuring compliance and operational sanity through scaling is kind of the easy part? The hard part is working with service owners to find out what they actually need instead of just giving everyone "allow notaction iam:* on *", but that's really just playing guess-and-check and spending a lot of time reading documentation (something your AWS team should be doing anyway). If you try to collaborative or self-service IAM it turns into a disaster almost immediately, in my experience.
|
|
#
?
Sep 6, 2019 01:17
|
|
|
Irritated Goat posted:I'm sure it's partly depression\ADHD talking but I don't know what I'm actually interested in. My brother recommended that because he knows I'm tired of generalization but failing the CCENT test 3 times makes me question how good I am if I"m not generalized. I do fine with general administration but apparently that's not enough to move past password resets and printers. As someone who took about a year to pass the CCENT and promptly failed the CCNA four times after that, don't get yourself down. When I finally passed it, it was somewhat due to comfort with how the tests worked. Go schedule the test again for November, this weekend. Find a date and do it. When it gets near and you are still unsure, reschedule it two weeks later. Just get it done before the switch. Work on subnetting and get your port numbers down. Spend 10 minutes a day reviewing flashcards. Sign up for udemy or something similar for some free lab time. Check if your library has e-learning resources. Above all, look around where you work. Talk to the people working in admin or engineering positions. Be curious about what they're doing, ask them if they have sources for you to research the tech they're working on. There is nothing wrong with growing comfortable in a role, but if you want change don't be afraid to work for it. If networling doesn't interest you, there is plenty out there to learn.
|
|
#
?
Sep 6, 2019 01:18
|
|
|
Being able to instantly subnet anything in my head is the stupidest super power.
|
|
#
?
Sep 6, 2019 01:33
|
|
|
Methanar posted:Being able to instantly subnet anything in my head is the stupidest super power. Honestly I thought it was the coolest thing until I actually had to start doing it because my boss thought it was a good idea to subnet every separate office of 3-10 people in the building into their own subnet and then we ran out so we had to supernet a bunch of poo poo and oh yeah they all need to share printers among other resources so that's fun.
|
|
#
?
Sep 6, 2019 03:09
|
|
|
This annoys me to an irrational level: The IT director personally assigns tickets to me and other field engineers. One of the first principles I learned in IT was Chain of Command. I never go above my boss for a request (always exceptions of course) and in same way my boss's boss doesn't personally hand out tickets to me (with rare exceptions). Four years in IT and this has been a constant... This IT director is a twit as best I can describe him, a talker and not much more. I don't like being assigned work by someone who isn't my immediate manager and can't follow standard practices. Same ticket from my manager or the senior manager I'd be fine. It annoys me that the IT director is just breaking common rules due to his position. He's really like the boss from Dilbert or Lombard from office space. My rule dealing with him is get his bullshit tickets done fast and avoid the guy (out of sight out of mind).
|
|
#
?
Sep 6, 2019 05:42
|
|
|
New job is very enterprise. I've been blocked on doing a thing for 2 weeks because we had a miscommunication of do we want to use the domain name name_long_long_long or name_short. We chose name_short, but another team is responsible for creating tls certs and created name_long_long_long and woops it took 2 weeks to fix that. I finally got the cert a few hours ago so hey I can do my thing now. Our k8s bootstrapping takes place before any chef runs to lay down things like public ssh keys and only a very small number of people are allowed to have the builtin key, and I'm not one of them yet. So this k8s bootstrapping is failing and I can't get in to see why. Cloudwatch logs are only telling me that it didn't work. I actually did reverse engineer this thing enough that I found a problem with our locking logic and manually cleared a phantom lock that was blocking progress. After clearing that though it still doesn't work but for a different reason and now its just a big ??? as to whats failing if I can't get in myself. Don't have any further log forwarding until chef runs, which it won't because k8s needs to be up first. There were a lot of other problems that happened in the process of even getting as far as I am. I've had people asking about when this is going to be up because its a blocker for them for over a week now and I kept giving the stupid answer of 'maybe end of day' because I kept hearing that I was getting the cert before end of day. So now I'm going to be blocked until I can get the attention of someone with the magic pre-chef build key. Comedy answer is to bake my own ami using the proper one as a base and stick my own ssh key in it and do a cluster build out on those to see why it doesn't work. i just wanna do my work man
|
|
#
?
Sep 6, 2019 05:48
|
|
|
Methanar posted:New job is very enterprise. Do you want to get your rake back?
|
|
#
?
Sep 6, 2019 05:54
|
|
|
jaegerx posted:Do you want to get your rake back? I hope somebody beats me to death with it
|
|
#
?
Sep 6, 2019 05:57
|
|
|
12 rats tied together posted:The hard part is working with service owners to find out what they actually need instead of just giving everyone "allow notaction iam:* on *", but that's really just playing guess-and-check and spending a lot of time reading documentation (something your AWS team should be doing anyway). We currently have it centralized 100% with my team (managed by Terraform, and extremely open to PR's). Because I agree self-service or collaborative IAM sounds even worse. But I think the first paragraph I quoted gets at the issue we're facing. We are the "AWS team". And the sever / network / security / Kubernetes / database / SRE team. And there's not many of us. So when someone comes to us and says "hey AWS just released this Glue/Athena/Lambda/whatever thing and we need to use it ASAP" it's a huge pain in the rear end. Because we have to do that guess-and-check and spend a lot of time reading documentation. Which would be less frustrating if the docs were good, but unless it's an ancient service like EC2/S3/RDS they're guaranteed to be incomplete or outright wrong. So you're back to guess-and-check as you so accurately put it. And as I said, there aren't many of us, so an engineer spending days reading docs, farting around with IAM, and waiting for the user to test and tell us what is still wrong is actually a major drag on our productivity. And in almost all cases, the requestor doesn't even know what they want or need, they just want to gently caress around with a new service. But that service needs permissions under iam:* to create some new role for itself and welp, we're back to guess-and-check. My hope is this is a temporary problem. We only started using AWS in earnest in the last 12 months, and setting up IAM policies has consumed a disproportionate amount of time. Amazon is constantly releasing new services, but I hope once we get the 10-20 our devs care about under control things will settle back down. Any time we figure out a service, we spam the IAM config out to all our accounts via Terraform, so it's been slowly improving. It's just been politically painful when we told everyone we were going to the cloud to increase velocity and then suddenly it's "HOLD UP WE GOTTA FIGURE OUT THIS SECURITY poo poo" at every turn. And to be clear, I totally want the cloud experience to be awesome and easy and fast and extremely  But I've also been around the block and know what happens if you #YOLO this poo poo. You end up on the national news.Very much want to find a happy medium. If someone has found a way to make this less of a hellscape that can only be solved by more people or man-hours, I am all ears. Docjowles fucked around with this message at 06:05 on Sep 6, 2019 |
|
#
?
Sep 6, 2019 05:59
|
|
|
I've done less work done in the last 2 months combined than I did in basically any week of my last job in the last year.
|
|
#
?
Sep 6, 2019 06:00
|
|
|
Methanar posted:I've done less work done in the last 2 months combined than I did in basically any week of my last job in the last year. I’ve been playing wow and have my laptop open for slack for the past week. WFH life is so great
|
|
#
?
Sep 6, 2019 06:02
|
|
|
jaegerx posted:I’ve been playing wow and have my laptop open for slack for the past week. WFH life is so great I should have just taken up a wow addiction recently, to be honest.
|
|
#
?
Sep 6, 2019 06:03
|
|
|
My rant above was written with WoW classic open, waiting for more boar asses to spawn.
|
|
#
?
Sep 6, 2019 06:08
|
|
|
Docjowles posted:My rant above was written with WoW classic open, waiting for more boar asses to spawn. Is it as good as everyone wanted it to be? Actually regretting right now that I didn't start playing wow or something alongside getting this new job. Might have made me less bored and lonely.
|
|
#
?
Sep 6, 2019 06:11
|
|
|
Methanar posted:Is it as good as everyone wanted it to be? Queues have dropped. Horde Herod has 200 people online pretty much all the time. I used to play wow in 2005 on my iBook while working 3rd shift at rackspace
|
|
#
?
Sep 6, 2019 06:16
|
|
|
Aunt Beth posted:Xerox’s devices are actually really good but the company that builds and sells and supports and maintains them is a disaster. I'll agree with this. I could write a couple of paragraphs on how to install, use, and update their technical bulletins database (a flat file would be an upgrade) and manage their bullshit password requirements. In fact, the hardware repair manager probably wishes I would  Even with the quality of the Versalink C600, we still ditched Xerox in favor of managed services from Ricoh. If they're an option, try them. If not, on the OPs original list I'd go with Canon. Actually, the Xerox 6027 is still in the catalog. It's a very nice color laser MF device meant for 1-4 people. That, and its big brother the faster printing 6515 are deeply discounted right now, which means they're being phased out. Taking that into account, $199 for a color laser/scanner unit is a pretty good bargain. In our experience they're very reliable units - we use them for the Field Sales team so they have to be.
|
|
#
?
Sep 6, 2019 06:30
|
|
|
Methanar posted:Is it as good as everyone wanted it to be? It's the worst game I've ever played and I quit already.
|
|
#
?
Sep 6, 2019 07:15
|
|
|
CLAM DOWN posted:It's the worst game I've ever played and I quit already. Dude. I was gonna send you my butter
|
|
#
?
Sep 6, 2019 07:33
|
|
|
Ahaha our product support just had a case where unknown devices were showing in a customer's platform.. Nobody knew where the devices were from, so a security issue was assumed, but it turns out they sent our silent installer through a zipped e-mail and ATP was installing the agent on the sandboxes and communicating with our platform.
|
|
#
?
Sep 6, 2019 12:35
|
|
|
Methanar posted:Is it as good as everyone wanted it to be? I mean it's original WoW, literally, so you know what you're getting into as there's like 15 years of takes available on it. I'm enjoying it. Part nostalgia trip (I used to play a ton from like release to 2009), part just legitimately great game that mostly holds up. I'm not gonna go back to playing it 24/7 like I did in my 20s but it's fun if you like MMOs. I'm also catching up with nerds I used to play with who I haven't talked to in like a decade which is cool. It's only $15 if you wanna give it a one month test run.
|
|
#
?
Sep 6, 2019 15:15
|
|
|
Methanar posted:I've done less work done in the last 2 months combined than I did in basically any week of my last job in the last year. Welcome to ~*Enterprise IT*~ I haven't done anything meaningful in almost 11 months. I'm at the point where I join conference calls about stuff I don't even work on just to fill time.
|
|
#
?
Sep 6, 2019 15:27
|
|
|
skipdogg posted:Welcome to ~*Enterprise IT*~ I haven't done anything meaningful in almost 11 months. I'm at the point where I join conference calls about stuff I don't even work on to provide value via cross-functional teaming. 
|
|
#
?
Sep 6, 2019 15:29
|
|
|
Docjowles posted:We currently have it centralized 100% with my team (managed by Terraform, and extremely open to PR's). Because I agree self-service or collaborative IAM sounds even worse. But I think the first paragraph I quoted gets at the issue we're facing. We are the "AWS team". And the sever / network / security / Kubernetes / database / SRE team. And there's not many of us. So when someone comes to us and says "hey AWS just released this Glue/Athena/Lambda/whatever thing and we need to use it ASAP" it's a huge pain in the rear end. Because we have to do that guess-and-check and spend a lot of time reading documentation. Which would be less frustrating if the docs were good, but unless it's an ancient service like EC2/S3/RDS they're guaranteed to be incomplete or outright wrong. So you're back to guess-and-check as you so accurately put it. And as I said, there aren't many of us, so an engineer spending days reading docs, farting around with IAM, and waiting for the user to test and tell us what is still wrong is actually a major drag on our productivity. And in almost all cases, the requestor doesn't even know what they want or need, they just want to gently caress around with a new service. But that service needs permissions under iam:* to create some new role for itself and welp, we're back to guess-and-check. Why don’t you have sandboxes that allow star on star for your early adopters who want to mess around with a new service? They can stand up stuff and play, and you can then break it with guess-and-check and build the iam policy for prod. Most of my customers take this approach and, while the guessing part sucks I admit, the implementation is much easier once the end user knows what they want to do. Also: MC chat- A few months back I stood up my own WotLk server and it is so much fun. I realize that I like playing MMOs without the first two Ms... Now I’m looking for a keyclone client so I can run 5- and 10-man raids by myself.
|
|
#
?
Sep 6, 2019 15:45
|
|
|
We have dev sandboxes where they have the canned PowerUser policy. Which I thought was going to be a good compromise, but it excludes working with IAM. And unfortunately more and more services need permission to gently caress with IAM on your behalf, or a preexisting role/policy they can use. Lambda execution policies, DynamoDB autoscaling policies, etc. Creating all those has been the time sink. I've definitely thought about giving them *:* and saying "you break it you buy it". But we've had security issues in the past when we were in the early Wild West phase of exploring AWS (user committing an access key with admin rights to GitHub leading to thousands of buttcoin miners launching in the account  , for example) so I am extremely hesitant to fully open it back up. No matter how much user education you do, it only takes one fuckup when everyone has full admin.
|
|
#
?
Sep 6, 2019 15:59
|
|
|
Docjowles posted:(user committing an access key with admin rights to GitHub leading to thousands of buttcoin miners launching in the account We had someone do this, too, and it was pretty impressive to re-create the attack through the API calls. Mainly because multiple attackers got the keys around the same time and were taking steps to ensure only they had access (rotating keys, etc). Also had someone who didn't understand the concepts of regions launch a HUGE RDS instance over in us-east-2 and promptly forget about it for a couple months because it didn't show up in his default selected region of us-east-1. Thankfully AWS takes pity on higher ed and waived it all, I think. Methanar posted:Our k8s bootstrapping takes place before any chef runs to lay down things like public ssh keys and only a very small number of people are allowed to have the builtin key, and I'm not one of them yet. So this k8s bootstrapping is failing and I can't get in to see why. Cloudwatch logs are only telling me that it didn't work. I'm also doing this (kops toolbox template -> tf, though) and have to do a bunch of dumb ssh hopping because core networking can't get direct connect working so I can't reach any private subnets...
|
|
#
?
Sep 6, 2019 16:19
|
|
|
Docjowles posted:So you're back to guess-and-check as you so accurately put it. And as I said, there aren't many of us, so an engineer spending days reading docs, farting around with IAM, and waiting for the user to test and tell us what is still wrong is actually a major drag on our productivity. And in almost all cases, the requestor doesn't even know what they want or need, they just want to gently caress around with a new service. But that service needs permissions under iam:* to create some new role for itself and welp, we're back to guess-and-check. I have no idea if this is a recommended standard but the way I like to do user permissions is users into groups, groups have a policy for "manage my own iam crap" and "assume a role named after my group", and then you put all of your actual permissions on the role. This way when you get the inevitable "Hey I kind of want to gently caress around with Glue" request you can have an admin assume the role for whoever that request came from and gently caress around with Glue in the web interface until they get error messages, resolve the error messages from their admin account, and then repeat until they are all gone or you have a ticket full of implementation details. The guess and check bullshit almost never goes away but if you can impersonate your users exact permissions with sts:AssumeRole you can shorten the feedback loop considerably.
|
|
#
?
Sep 6, 2019 17:40
|
|
|
Oh good morning to me, client's 2019 fileserver, which has been running fine for a little over a month now, decided it wanted to start rebooting every 20-30 minutes today. Nothing has changed, why you break!?!
|
|
#
?
Sep 6, 2019 18:52
|
|
|
Is it properly licensed? As in, (assuming it's a Windows box) is it able to get a license from KMS/MAK?
|
|
#
?
Sep 6, 2019 19:34
|
|
|
Wizard of the Deep posted:Is it properly licensed? As in, (assuming it's a Windows box) is it able to get a license from KMS/MAK? Yeah it's a datacenter license, it's a MAK and there are no complaints about that. In fact there are no complaints at all prior to the restarts, the only common thing I see between restarts in the event log are the following 2 events always precede the restart event: Event 1: Source: FilterManager Event ID: 6 Level: Information General: File System Filter 'FileCrypt' (10.0, 2070-12-15T19:13:56.000000000Z) has successfully loaded and registered with Filter Manager. Event 2: Source: FilterManager Event ID: 6 Level: Information General: File System Filter 'npsvctrig' (10.0, 2094-02-20T06:14:30.000000000Z) has successfully loaded and registered with Filter Manager. Though I doubt they are the cause of the restart in and of themselves. SFC found some corruption and repaired, but running it again has the same results with the same errors that it is finding.
|
|
#
?
Sep 6, 2019 19:50
|
|
|
Wizard of the Deep posted:Is it properly licensed? As in, (assuming it's a Windows box) is it able to get a license from KMS/MAK? Wait... why would this cause it to reboot every 20-30 minutes? I've only ever seen it complain about being a non-legit copy of Windows MF_James posted:Yeah it's a datacenter license, it's a MAK and there are no complaints about that. In fact there are no complaints at all prior to the restarts, the only common thing I see between restarts in the event log are the following 2 events always precede the restart event: Does it actually "restart" or is it a hard crash and a boot up?
|
|
#
?
Sep 6, 2019 19:52
|
|
|
TheFace posted:Wait... why would this cause it to reboot every 20-30 minutes? I've only ever seen it complain about being a non-legit copy of Windows I was mixing some wires. Windows servers that are on an evaluation license will automatically reboot every 60 minutes after the eval period. TheFace posted:Does it actually "restart" or is it a hard crash and a boot up? That's a good point. There should be power events related to shutting down if they can be written at all.
|
|
#
?
Sep 6, 2019 20:13
|
|
|
TheFace posted:Wait... why would this cause it to reboot every 20-30 minutes? I've only ever seen it complain about being a non-legit copy of Windows Sorry, it is a crash rather than a restart, bad me for using the wrong terminology. Digging through dump file(s) now to see what the root cause is.
|
|
#
?
Sep 6, 2019 20:22
|
|
|
Docjowles posted:I've definitely thought about giving them *:* and saying "you break it you buy it". We do this with our lower environments, plus Cloud Custodian with triggers to shutdown everything and kill accounts/roles when they go above the budget threshold. You can't fix stupid though. For Prod, where we need to give out access to groups outside of ours, we use Turbot. It's a little expensive, but I was able to make the argument that we either buy it or hire 2 or more folks to write IAM policies.
|
|
#
?
Sep 6, 2019 20:26
|
|
|
I love it when a new dev cuts an incident claiming that our entire version control system is broken because he can't check in his source code and then it turns out that the dev doesn't know how to generate a public/private keypair for BitBucket. So much for the onboarding process. It's even more fun when the dev is on the other side of the planet, so you need to call them at 2100 your time to find out what is actually going on. tango alpha delta fucked around with this message at 22:35 on Sep 6, 2019 |
|
#
?
Sep 6, 2019 22:30
|
|
|
tango alpha delta posted:I love it when a new dev cuts an incident claiming that our entire version control system is broken because he can't check in his source code and then it turns out that the dev doesn't know how to generate a public/private keypair for BitBucket. he's an old dev now, right?
|
|
#
?
Sep 6, 2019 23:08
|
|
|
Spent 3 hours reverse engineering k8s cluster build out failures. It was DNS. In two different ways. New environment wasn't properly forwarding .compute.internal to ec2 metadata through an elaborate chain of dnsmasq and pdns because chef wasn't restarting pdns after modifying config files for some reason. Other scripts were also broken because somewhere somehow something wasn't putting in an fqdn even though other clusters I'm looking at which use the same scripts were getting an fqdn. I don't really understand why but I'm pretty sure its because us-east-1 uses ec2.internal while everything else uses something like us-west-1.compute.internal This manifests in a really dumb way that involved base64 decoding and using openssl to look at the CNs on a certificate which is the clue you actually need to figure this out, which is not something you can grep for. Ec2 is also injecting resolv.conf-style search domains somewhere, I guess and I can't find where but whatever. Plus a bunch of other bullshit.
|
|
#
?
Sep 7, 2019 00:06
|
|
|
GnarlyCharlie4u posted:Honestly I thought it was the coolest thing until I actually had to start doing it because my boss thought it was a good idea to subnet every separate office of 3-10 people in the building into their own subnet and then we ran out so we had to supernet a bunch of poo poo and oh yeah they all need to share printers among other resources so that's fun. Last year, my environment implemented a separate subnet for all networked printers, because every regular-assed network jack was getting a public-facing IP address, and they wanted to control printer-based external exploits. Y'know... as opposed to say, putting all mundane ports on firewalled, internal only IP's. Network printers plugged into public IP space ports get remediated to a 'black hole' range almost as instantly as they're plugged in, by a human sitting at a desk that sees the flag thrown. It takes a week after either removing the printer, or asking them to move the port to the printer IP space, for them to fix the black holed port. Because they're dicks like that. This summer, after years of buckling to criticism as to how every wall network jack could grant a person a public IP address no matter who they were (there isn't even so much as a NAC running here), they finally change over all but a handful of approved servers to internal IP space, taking a huge stride forward in campus network security. The network printer policy, which is now thoroughly de-necessitated by the new IP assignment method, is still rigidly enforced, and remediated in the same slow, couldn't-give-a-gently caress timeframe.
|
|
#
?
Sep 7, 2019 00:43
|
|
|
|
| # ? May 25, 2024 10:03 |
|
|
It might sound stupid but I find it impressive that I can have a terminal open inside visual studio and control Docker from it. Sci-fi poo poo.
|
|
#
?
Sep 7, 2019 01:30
|
|
