I put my two weeks in and confirmed today that the 9th would be my last day. My current boss called me in and asked why I was leaving.
I let them know exactly why I was leaving. It wasn't pretty, but it wasn't like I blew up at him. My boss and supervisor have been aces.
Basically I did what I could so the people staying here stop getting all this fucking bullshit from other departments who shove their jobs on us because they just don't feel like doing them anymore.
jungleroomx on
+7
jungleroomxIt's never too many graves, it's always not enough shovelsRegistered Userregular
Like I said before, I was considering it until we got development pulling some bullshit as per the norm.
And then today we have development AND conversions pulling bullshit as per the norm.
Also, sales, who sold them a certain interface for a software package but GAVE THEM A FREE FUCKING HOSTED SERVER.
Any of you guys dealing with the new EU GDPR compliance? I don't work in IT but we handle personal data, so it's been "a thing" here for the past year. "What do you mean we can't store everything in those cheap offshore servers anymore?!? Can we use 'the cloud'? By the way, what is 'the cloud'?"
/facepalm
Dealing with this in that we have to request exemption access every time we need to troubleshoot a downed host in the EU. In the next couple of months theyre going to officially start setting up the EU office to pick up that work, though.
"excuse my French
But fuck you — no, fuck y'all, that's as blunt as it gets"
- Kendrick Lamar, "The Blacker the Berry"
I'm taking a class on securing Linux systems this semester, the only previous experience I have previously is some very light Red Hat experience when I worked at the movie theater, and most of the stuff I was locked out of, even as the manager of the projection booth.
I gotta say, wow! Its just really easy once you get the commands down and its so useful. It use to intimidate the hell out of me when I was younger, but now, its great.
idiot IT that say "nou" when you tell them that they're the ones that have the problem after they tell you "the problem is on your end" are frustrating
idiot IT that say "nou" when you tell them that they're the ones that have the problem after they tell you "the problem is on your end" are frustrating
idiot IT that say "nou" when you tell them that they're the ones that have the problem after they tell you "the problem is on your end" are frustrating
The worst is when you're that guy.
As long as you have the proof to back up the claim, by all means.
That's one of my vendors and the constant issues with have with that app. He always blames it on my network. There's only so much I can do to show you that my connectivity to your server is lightning fast over the 1gig fiber, but as soon as we try to use your app it's like we're on dial up sometimes. And no, you don't need more RAM or cores on your server, you are only actively using half of what we've allocated you last time you complained and that's when we're busy. It often sits below 10%.
is it unreasonable for me to consider this situation bullshit?
we have an SCCM that pushes out all sorts of applications
worked with the SCCM team to get some newer ones packaged up and put into the sytem
on some machines shit just doesn't install, you hit go, it no go
deskside does the basic troubleshooting, make sure SCCM is installed right, updates are up to date, the computer isn't obviously fucked, etc
send ticket up to SCCM team all like "hey this package doesn't work right"
it gets kicked back down to deskside all "please troubleshoot, here's a big bullshit list of reqs before we'll look at the ticket" (want error codes [lol it fails silently], all sorts of logs, dumb bullshit like ip and mac address)
I'm over here like... motherfuckers you're Tier 3 not us
do your damn job and fix your services
life's a game that you're bound to lose / like using a hammer to pound in screws
fuck up once and you break your thumb / if you're happy at all then you're god damn dumb
that's right we're on a fucked up cruise / God is dead but at least we have booze
bad things happen, no one knows why / the sun burns out and everyone dies
That's one of my vendors and the constant issues with have with that app. He always blames it on my network. There's only so much I can do to show you that my connectivity to your server is lightning fast over the 1gig fiber, but as soon as we try to use your app it's like we're on dial up sometimes. And no, you don't need more RAM or cores on your server, you are only actively using half of what we've allocated you last time you complained and that's when we're busy. It often sits below 10%.
Tell them to increase the buffer size they're allocating for TCP inside their application. I've seen this exact thing happen where someone will start with like a 1kb buffer in their software and never change it and their app reads at 1kb per tick or whatever they defined for reading packets.
is it unreasonable for me to consider this situation bullshit?
we have an SCCM that pushes out all sorts of applications
worked with the SCCM team to get some newer ones packaged up and put into the sytem
on some machines shit just doesn't install, you hit go, it no go
deskside does the basic troubleshooting, make sure SCCM is installed right, updates are up to date, the computer isn't obviously fucked, etc
send ticket up to SCCM team all like "hey this package doesn't work right"
it gets kicked back down to deskside all "please troubleshoot, here's a big bullshit list of reqs before we'll look at the ticket" (want error codes [lol it fails silently], all sorts of logs, dumb bullshit like ip and mac address)
I'm over here like... motherfuckers you're Tier 3 not us
do your damn job and fix your services
I mean...having been "tier 3"...by the time a ticket got to me I expected routine troubleshooting and log/information collection to have been done. you don't need that level of knowledge to collect basic information so someone at that level doing it is theoretically a waste of time.
now, usually it was faster for me to get what I needed myself, but depending on the organization they may be getting told to force their processes to be followed even if it slows a ticket down, etc.
is it unreasonable for me to consider this situation bullshit?
we have an SCCM that pushes out all sorts of applications
worked with the SCCM team to get some newer ones packaged up and put into the sytem
on some machines shit just doesn't install, you hit go, it no go
deskside does the basic troubleshooting, make sure SCCM is installed right, updates are up to date, the computer isn't obviously fucked, etc
send ticket up to SCCM team all like "hey this package doesn't work right"
it gets kicked back down to deskside all "please troubleshoot, here's a big bullshit list of reqs before we'll look at the ticket" (want error codes [lol it fails silently], all sorts of logs, dumb bullshit like ip and mac address)
I'm over here like... motherfuckers you're Tier 3 not us
do your damn job and fix your services
I mean.. they could maybe be nicer about it, but I don't know if I'd jump straight to "this is bullshit"?
Every goddamn time I see loopback processing enabled in group policy my immediate reaction is that the person who enabled it either doesn't actually know what it does, or couldn't figure out how to make shit work the right way.
I'm drawing off of my experiences of never actually seeing this team fix any issues
for instance every computer on the domain constantly has a 'new software is available' popup
or the countless windows updates that just fail with no error message, constantly try to reinstall filling up the hard drive with broken CAB files, even if you've installed the update manually with the KB exe (which worked just fine???)
i dunno, like, when I've been in charge of services like that I don't really need lower tier techs attaching random logfiles to a ticket, that's generally useless for me
sure screenshot an error if you got it but just let me know you did the basic reboot/reinstall shit
the whole point of this kind of automation system is that it works and the base level techs shouldn't have to have the advanced troubleshooting knowledge, y'know? The people in charge of the service should be treating service failures as an important issue instead of an annoyance
sigh
life's a game that you're bound to lose / like using a hammer to pound in screws
fuck up once and you break your thumb / if you're happy at all then you're god damn dumb
that's right we're on a fucked up cruise / God is dead but at least we have booze
bad things happen, no one knows why / the sun burns out and everyone dies
+4
CambiataCommander ShepardThe likes of which even GAWD has never seenRegistered Userregular
Guyz I tried to google this without much luck, does someone here know? When I run fdisk on a xen host, I get a lot of /dev/tda, /dev/tdb, etc through most of the alphabet. Are those just representations of the VMs on Xenserver? The only answer I could find on google said those are fans, but no way do I believe that.
"excuse my French
But fuck you — no, fuck y'all, that's as blunt as it gets"
- Kendrick Lamar, "The Blacker the Berry"
Guyz I tried to google this without much luck, does someone here know? When I run fdisk on a xen host, I get a lot of /dev/tda, /dev/tdb, etc through most of the alphabet. Are those just representations of the VMs on Xenserver? The only answer I could find on google said those are fans, but no way do I believe that.
hard to say, looks like it's something related to xenserver
Guyz I tried to google this without much luck, does someone here know? When I run fdisk on a xen host, I get a lot of /dev/tda, /dev/tdb, etc through most of the alphabet. Are those just representations of the VMs on Xenserver? The only answer I could find on google said those are fans, but no way do I believe that.
hard to say, looks like it's something related to xenserver
Yeah I'm not sure on that. We moved away from xen, but I still have a xen host running, and it doesn't have those. And in any of the virtuals I just get /dev/xvda#
Google seems to turn up nothing but xen shit, so it's definitely a xen thing, but what it actually is doesn't seem to be a question anyone's asking/answering.
And this is why I'm constantly abandoning projects I like, for newer projects I like a little less.
Guyz I tried to google this without much luck, does someone here know? When I run fdisk on a xen host, I get a lot of /dev/tda, /dev/tdb, etc through most of the alphabet. Are those just representations of the VMs on Xenserver? The only answer I could find on google said those are fans, but no way do I believe that.
Best guess is "td*" is for flash storage as opposed to the "hd*" of spinning disks.
Just remember that half the people you meet are below average intelligence.
I'm not a Xenserver guy, but here's what I'm seeing from a "get smart quick" Google:
"tda" is short for tapdisk, which is a Xenserver term.
A tapdisk appears to be an abstraction layer for virtual disks that acts basically as read and write caching. The virtual disk (VHD) is mounted as tda, tdb, tdc, etc. Reads and writes are sent to the tapdisk service first, before they're committed to the VHD.
I might be slightly inaccurate here because I literally just read up on this.
What I cannot determine is if there's a 1:1 correspondence between a mounted tapdisk and it's underlying VHD, or if tapdisks work more like linked clones.
Here are some articles I found mildly illuminating, but I still have many unanswered questions:
Guyz I tried to google this without much luck, does someone here know? When I run fdisk on a xen host, I get a lot of /dev/tda, /dev/tdb, etc through most of the alphabet. Are those just representations of the VMs on Xenserver? The only answer I could find on google said those are fans, but no way do I believe that.
Best guess is "td*" is for flash storage as opposed to the "hd*" of spinning disks.
Nah, they use "sd" for all SATA and USB connected storage. Doesn't matter if it's solid state or not.
For example, I have a spinning hard drive, an SSD, and a flash drive plugged into a USB port, and they are all listed as:
/dev/sda - my SSD
/dev/sdb - my 1.0 TB hard drive
/dev/sdc - my flash drive
I'm drawing off of my experiences of never actually seeing this team fix any issues
for instance every computer on the domain constantly has a 'new software is available' popup
or the countless windows updates that just fail with no error message, constantly try to reinstall filling up the hard drive with broken CAB files, even if you've installed the update manually with the KB exe (which worked just fine???)
i dunno, like, when I've been in charge of services like that I don't really need lower tier techs attaching random logfiles to a ticket, that's generally useless for me
sure screenshot an error if you got it but just let me know you did the basic reboot/reinstall shit
the whole point of this kind of automation system is that it works and the base level techs shouldn't have to have the advanced troubleshooting knowledge, y'know? The people in charge of the service should be treating service failures as an important issue instead of an annoyance
sigh
99% chance the SCCM team is horribly understaffed. Maybe they don't even have dedicated SCCM people and they just had random Windows server techs implement it.
In my experience, SCCM needs a lot of babysitting. I feel like if you have SCCM you need at least two people who are 100% dedicated to doing all SCCM all the time.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
Posts
I guess I could just link to "A tale of porn, drugs, spam" google results and make that my sig.
That seems like it would end up as a trip to HR.
Mostly off, I assume.
also, Ladies
Now you're just gunning for it and it's less fun.
Way to ruin it.
I just got asked what my reason is for not leaving.
That was their first mistake.
GOTTEM
didn't you just accept another job?
wat
You didn't take the offer and stay did you?
XBL:Phenyhelm - 3DS:Phenyhelm
No.
I put my two weeks in and confirmed today that the 9th would be my last day. My current boss called me in and asked why I was leaving.
I let them know exactly why I was leaving. It wasn't pretty, but it wasn't like I blew up at him. My boss and supervisor have been aces.
Basically I did what I could so the people staying here stop getting all this fucking bullshit from other departments who shove their jobs on us because they just don't feel like doing them anymore.
And then today we have development AND conversions pulling bullshit as per the norm.
Also, sales, who sold them a certain interface for a software package but GAVE THEM A FREE FUCKING HOSTED SERVER.
Yeah nah fuck this.
This is why people were confused.
That's not my reason for not being confused.
the "no true scotch man" fallacy.
It's their version of jrxnotleavingsayswhat?
Oh shit my bad lol
Dealing with this in that we have to request exemption access every time we need to troubleshoot a downed host in the EU. In the next couple of months theyre going to officially start setting up the EU office to pick up that work, though.
But fuck you — no, fuck y'all, that's as blunt as it gets"
- Kendrick Lamar, "The Blacker the Berry"
I gotta say, wow! Its just really easy once you get the commands down and its so useful. It use to intimidate the hell out of me when I was younger, but now, its great.
The worst is when you're that guy.
As long as you have the proof to back up the claim, by all means.
we have an SCCM that pushes out all sorts of applications
worked with the SCCM team to get some newer ones packaged up and put into the sytem
on some machines shit just doesn't install, you hit go, it no go
deskside does the basic troubleshooting, make sure SCCM is installed right, updates are up to date, the computer isn't obviously fucked, etc
send ticket up to SCCM team all like "hey this package doesn't work right"
it gets kicked back down to deskside all "please troubleshoot, here's a big bullshit list of reqs before we'll look at the ticket" (want error codes [lol it fails silently], all sorts of logs, dumb bullshit like ip and mac address)
I'm over here like... motherfuckers you're Tier 3 not us
do your damn job and fix your services
fuck up once and you break your thumb / if you're happy at all then you're god damn dumb
that's right we're on a fucked up cruise / God is dead but at least we have booze
bad things happen, no one knows why / the sun burns out and everyone dies
Tell them to increase the buffer size they're allocating for TCP inside their application. I've seen this exact thing happen where someone will start with like a 1kb buffer in their software and never change it and their app reads at 1kb per tick or whatever they defined for reading packets.
I mean...having been "tier 3"...by the time a ticket got to me I expected routine troubleshooting and log/information collection to have been done. you don't need that level of knowledge to collect basic information so someone at that level doing it is theoretically a waste of time.
now, usually it was faster for me to get what I needed myself, but depending on the organization they may be getting told to force their processes to be followed even if it slows a ticket down, etc.
I mean.. they could maybe be nicer about it, but I don't know if I'd jump straight to "this is bullshit"?
I'm drawing off of my experiences of never actually seeing this team fix any issues
for instance every computer on the domain constantly has a 'new software is available' popup
or the countless windows updates that just fail with no error message, constantly try to reinstall filling up the hard drive with broken CAB files, even if you've installed the update manually with the KB exe (which worked just fine???)
i dunno, like, when I've been in charge of services like that I don't really need lower tier techs attaching random logfiles to a ticket, that's generally useless for me
sure screenshot an error if you got it but just let me know you did the basic reboot/reinstall shit
the whole point of this kind of automation system is that it works and the base level techs shouldn't have to have the advanced troubleshooting knowledge, y'know? The people in charge of the service should be treating service failures as an important issue instead of an annoyance
sigh
fuck up once and you break your thumb / if you're happy at all then you're god damn dumb
that's right we're on a fucked up cruise / God is dead but at least we have booze
bad things happen, no one knows why / the sun burns out and everyone dies
But fuck you — no, fuck y'all, that's as blunt as it gets"
- Kendrick Lamar, "The Blacker the Berry"
hard to say, looks like it's something related to xenserver
This will help you dive deeper into it:
https://unix.stackexchange.com/questions/97676/how-to-find-the-driver-module-associated-with-a-device-on-linux/125272#125272
Might be easier to ask another admin though
Oh I already asked a specialist and he didn't know. My lead should be in today though, so I could ask him. He knows a lot of shit.
But fuck you — no, fuck y'all, that's as blunt as it gets"
- Kendrick Lamar, "The Blacker the Berry"
Google seems to turn up nothing but xen shit, so it's definitely a xen thing, but what it actually is doesn't seem to be a question anyone's asking/answering.
And this is why I'm constantly abandoning projects I like, for newer projects I like a little less.
Best guess is "td*" is for flash storage as opposed to the "hd*" of spinning disks.
"tda" is short for tapdisk, which is a Xenserver term.
A tapdisk appears to be an abstraction layer for virtual disks that acts basically as read and write caching. The virtual disk (VHD) is mounted as tda, tdb, tdc, etc. Reads and writes are sent to the tapdisk service first, before they're committed to the VHD.
I might be slightly inaccurate here because I literally just read up on this.
What I cannot determine is if there's a 1:1 correspondence between a mounted tapdisk and it's underlying VHD, or if tapdisks work more like linked clones.
Here are some articles I found mildly illuminating, but I still have many unanswered questions:
http://xenserver.org/blog/entry/read-caching.html
http://xenserver.org/blog/entry/tapdisk3.html
And this old PDF link:
https://doc.yonyoucloud.com/doc/xen/xs6.1.0-storage-performance-guide.pdf
the "no true scotch man" fallacy.
What is work?
Nah, they use "sd" for all SATA and USB connected storage. Doesn't matter if it's solid state or not.
For example, I have a spinning hard drive, an SSD, and a flash drive plugged into a USB port, and they are all listed as:
/dev/sda - my SSD
/dev/sdb - my 1.0 TB hard drive
/dev/sdc - my flash drive
99% chance the SCCM team is horribly understaffed. Maybe they don't even have dedicated SCCM people and they just had random Windows server techs implement it.
In my experience, SCCM needs a lot of babysitting. I feel like if you have SCCM you need at least two people who are 100% dedicated to doing all SCCM all the time.
the "no true scotch man" fallacy.