|
I wonder if all the people using startx have ever taken a look at the source code for it:code:
|
#
?
Feb 24, 2014 21:46
|
|
|
|
| # ? May 9, 2024 21:18 |
|
|
evol262 posted:Fedora, CentOS, Debian, and Ubuntu all support some kind of "minimal" install which lets you pick and choose exactly what you want to install. Unless you're picking CrunchBang, Fedora $something Remix, or other which is designed to come with a specific DE. I haven't used Fedoras "minimal" installer but if it's anything like Debians it's probably pretty great. The Debian one does everything for you via an easy to use curses interface. Then you can select different package groups like SSH server or Desktop Environment. For my headless file server I used that installer, selected SSH server and unticked the rest. It's pretty boss. Suspicious Dish posted:I wonder if all the people using startx have ever taken a look at the source code for it: So you're telling me I'm running the equivalent of an API hello world example to run X?  What exactly is the alternative? And what's the functional difference between calling things when X starts or calling them when the windows manager starts in a standard desktop environment?
|
|
#
?
Feb 24, 2014 22:56
|
|
|
Xik posted:I haven't used Fedoras "minimal" installer but if it's anything like Debians it's probably pretty great. The Debian one does everything for you via an easy to use curses interface. Then you can select different package groups like SSH server or Desktop Environment. For my headless file server I used that installer, selected SSH server and unticked the rest. It's pretty boss. Anaconda's package sets are fabulous, really. You should use a take a look at a "real" (non-Live, meaning net or full-DVD) CentOS, RHEL, or Fedora installer some time if you like Debian's.
|
|
#
?
Feb 24, 2014 23:03
|
|
|
evol262 posted:Anaconda's package sets are fabulous, really. You should use a take a look at a "real" (non-Live, meaning net or full-DVD) CentOS, RHEL, or Fedora installer some time if you like Debian's. Yep, I do plan to at some stage. I'd eventually like to get out of the help desk and into a Linux Admin role at some point (still years away yet). Playing with CentOS/RHEL and the RPM system is high on the list due to obvious reasons.
|
|
#
?
Feb 24, 2014 23:15
|
|
|
Xik posted:So you're telling me I'm running the equivalent of an API hello world example to run X? The X server needs to be run as root. In order to start things as root, Xorg has the "setuid" bit set, which says that it runs as root privileges. The unfortunate thing about setuid binaries is that the environment isn't cleaned out when you execute them. It's also very hard to properly clean such an environment in bash. Display managers like gdm and kdm are very careful to launch Xorg in a limited environment, and ensure that it's working fine. As for xinitrc, the issue is that any complicated Linux desktop needs to guarantee ordering, that some daemons or components are launched before others. In this case, we need to carefully make sure that everything is initialized before starting any applications. So this is why we recommend dropping a .desktop file in ~/.local/share/applications/ instead of launching it as part of xinitrc.
|
|
#
?
Feb 24, 2014 23:42
|
|
|
Suspicious Dish posted:The X server needs to be run as root. In order to start things as root, Xorg has the "setuid" bit set, which says that it runs as root privileges. The unfortunate thing about setuid binaries is that the environment isn't cleaned out when you execute them. It's also very hard to properly clean such an environment in bash. But part of the Arch experience is figuring out where you're supposed to put "gnome-settings-daemon &" in order to make it work. It teaches you about Linux 
|
|
#
?
Feb 25, 2014 01:59
|
|
|
So, say I accidentally wiped my EFI partition, and set it back up with just my Linux loader and GRUB. How can I go about adding my Windows 8 partition back? I can't do the grub-probe command because there's no "/boot/EFI/Microsoft/..." to probe. Do I need to scrounge up a Windows 8 DVD to fix my MBR?
|
|
#
?
Feb 25, 2014 04:52
|
|
|
QPZIL posted:So, say I accidentally wiped my EFI partition, and set it back up with just my Linux loader and GRUB. How can I go about adding my Windows 8 partition back? I can't do the grub-probe command because there's no "/boot/EFI/Microsoft/..." to probe. Do I need to scrounge up a Windows 8 DVD to fix my MBR? Doesn't Windows stuff these under /Windows/Boot/EFI? Mount your partition and copy them?
|
|
#
?
Feb 25, 2014 05:23
|
|
|
Motherboard swap went fine. I spent hours cleaning out dust from the case and all the other components with a brush. Then spent way too long trying to get all the wires looking pretty. The normal kernel wouldn't boot, but the fallback did. From there I recreated the initramfs and rebooted into the main system. It was saying it couldn't find the root device (based on the UUID). I don't know much about what happens during that initial boot, but my assumption is that the old ram fs was setup to load the module for my old SATA controller so it wasn't able to find the disk with the new motherboard. Is that right? I still don't understand why the fallback loaded though. Network was fine. I didn't have to reconfigure that after I remembered to plug the Ethernet cable back in .My backup Windows drive wouldn't load though. I got an instant BSOD before it would boot. I'll look into it later...
|
|
#
?
Feb 25, 2014 06:06
|
|
|
QPZIL posted:So, say I accidentally wiped my EFI partition, and set it back up with just my Linux loader and GRUB. How can I go about adding my Windows 8 partition back? I can't do the grub-probe command because there's no "/boot/EFI/Microsoft/..." to probe. Do I need to scrounge up a Windows 8 DVD to fix my MBR? There is no functional MBR in a EFI-bootable system. Instead, what you need is to reconstruct the Boot Configuration Data (BCD) store and to copy the Windows EFI bootloader back in the right place. Yes, the Windows 8 DVD has some helpful recovery functions and tools to do it. The Windows EFI bootloader components (bootmgfw.efi, bootmgr.efi and memtest.efi, and the corresponding *.efi.mui components of the appropriate language/locale) can be copied from the Windows C: partition, but the BCD needs to be recreated. This might be helpful: http://www.fixedbyvonnie.com/2013/12/how-to-repair-the-efi-bootloader-in-windows-8/ (Now that you mention it... I think I should stash a backup copy of the Windows EFI bootloader of my dual-boot system in some Linux-accessible location, just in case.)
|
|
#
?
Feb 25, 2014 07:39
|
|
|
telcoM posted:There is no functional MBR in a EFI-bootable system. Instead, what you need is to reconstruct the Boot Configuration Data (BCD) store and to copy the Windows EFI bootloader back in the right place. Yes, the Windows 8 DVD has some helpful recovery functions and tools to do it. Exactly what I was looking for! Thanks!
|
|
#
?
Feb 25, 2014 14:36
|
|
|
evol262 posted:Yeah. Who needs SElinux?
|
|
#
?
Feb 25, 2014 15:56
|
|
|
I disable SELinux. Mainly to prevent the journal spam and 3000 python plugins running any time I do something slightly out of the ordinary.
|
|
#
?
Feb 25, 2014 16:06
|
|
|
SELinux only needs to save your rear end one time for it to be worth the minor hassle of knowing how to run "restorecon" or "setsebool"
|
|
#
?
Feb 25, 2014 16:30
|
|
|
Misogynist posted:This is a question most CentOS users ask immediately before disabling it. This is why dwalsh has the worst job. SElinux misbehaving? Don't bother filing a bug. Just disable it and let the developer work blind. And disabling it on your actual system is fine if you don't need to build SElinux-enabled images (I do, and it's not possible to use appliance-tools to build SElinux images without SElinux turned on :/), but for a container that should only be running one thing anyway and support in upstream LXC, there's little reason for Docker not to support it.
|
|
#
?
Feb 25, 2014 16:40
|
|
|
The fun SELinux bug was when the policy had a bug preventing updates from being applied. So of course you couldn't get the bugfix update that fixed the policy.
|
|
#
?
Feb 25, 2014 17:04
|
|
|
What is a mechanism whereby a device could figure out what IP address it has, and email that, even if the router it is hooked up to changes? I'm thinking about some kind of dynamic update utility (DynDNS?) that lets the device understand when it is placed on to a new network, and then call home. For example an embedded system on a LAN which could be robust even if the LAN access point (router) gets changed, without direct on-site user intervention. The user in this case could only communicate over the internet with the device. Is this possible? There was a defcon talk where the guy's stolen mac laptop reappeared on the net a year later because the DynDNS updating software did something, but he didn't go in to details on how that works.
|
|
#
?
Feb 25, 2014 19:31
|
|
|
reading posted:What is a mechanism whereby a device could figure out what IP address it has, and email that, even if the router it is hooked up to changes? I'm thinking about some kind of dynamic update utility (DynDNS?) that lets the device understand when it is placed on to a new network, and then call home. Just use cron, which is basically what the DynDNS stuff uses. You could use udev triggers to run some script every time the cable is plugged and unplugged, but just have a cron job check its IP and hit some API you set up, or upload a trivial text file on FTP somewhere, or with passwordless SSH, or whatever.
|
|
#
?
Feb 25, 2014 19:51
|
|
|
Misogynist posted:This is a question most CentOS users ask immediately before disabling it. I haven't disabled SELinux on a desktop since ~2005/6 back then the Nvidia drivers wouldn't work with it out of the box on Fedora. If it is really slowing you down set it to permissive and check what it is logging and then change the settings to allow what you are trying to do.
|
|
#
?
Feb 25, 2014 22:05
|
|
|
When I was doing my RHCE bootcamp, the instructor said, with a straight face, "Everyone should run SELinux. It's not that hard to configure and debug! Come on guys!" Everyone there there rolled their eyes. Including me. "Step 1, disable SELinux" is scattered among all sorts of official RH documentation too; satellite server won't even run with SELinux enabled. I remember a few years ago when it made it into the default install for the first time. All I have to say is thank you, permissive mode! Edit: Cidrick posted:SELinux only needs to save your rear end one time for it to be worth the minor hassle of knowing how to run "restorecon" or "setsebool" SEL as a versioning / provisioning / restore tool? Shame on you! Bhodi fucked around with this message at 22:19 on Feb 25, 2014 |
|
#
?
Feb 25, 2014 22:16
|
|
|
I suspect these must be the same people telling me that yes, UEFI defintely works now and I should not turn on legacy emulation, and then can't tell me why UEFI doesn't work or how to fix it.
|
|
#
?
Feb 25, 2014 22:19
|
|
|
Bhodi posted:When I was doing my RHCE bootcamp, the instructor said, with a straight face, "Everyone should run SELinux. It's not that hard to configure and debug! Come on guys!" Bhodi posted:"Step 1, disable SELinux" is scattered among all sorts of official RH documentation too; satellite server won't even run with SELinux enabled. Bhodi posted:I remember a few years ago when it made it into the default install for the first time. All I have to say is thank you, permissive mode! Bhodi posted:SEL as a versioning / provisioning / restore tool? Shame on you! Traditional UNIX permissions are absolutely not sufficient. Windows has more granular security. Learn SELinux. Or use a grsec kernel. Or use AppArmor. Or whatever. I don't care. But "lol, SELinux causes problems, just disable it" is absurd. scroogle nmaps posted:I suspect these must be the same people telling me that yes, UEFI defintely works now and I should not turn on legacy emulation, and then can't tell me why UEFI doesn't work or how to fix it.
|
|
#
?
Feb 25, 2014 22:29
|
|
|
evol262 posted:Look at audit.log and learn to use audit2allow. Run in permissive for a day or so, generate rules with audit2allow, then run enforcing. My favorite thing is how the lines tell you to pipe grep into audit2allow and chop off the process name to 10 chars or something, leaving for a fairly simple dumb hole where the process name is different 10 chars in. Yes, please, let a tool munge a human-readable log message and try to figure out a security policy based on that. What a great idea. Also, it's local-only and hard to replicate, and it doesn't store the policy separately so you can't easily do the modification, and then revert to close up any leaks you might have had.
|
|
#
?
Feb 25, 2014 22:34
|
|
|
Suspicious Dish posted:My favorite thing is how the lines tell you to pipe grep into audit2allow and chop off the process name to 10 chars or something, leaving for a fairly simple dumb hole where the process name is different 10 chars in. audit2allow absolutely has the option to generate policy files (-M), which you can distribute and insert on new systems trivially (semodule -i). I'm too lazy to write policy files by hand, so I do this frequently. The big problem with audit.log is that the logfile format is terrible. Even though it is technically human readable, it's ludicrously verbose, and finding exactly which denial you care about allowing can be an exercise in frustration.
|
|
#
?
Feb 25, 2014 22:40
|
|
|
Stop stop stop. For 99% of servers selinux is not only not helpful, but is disadvantageous because of the additional work to administrate. Given a limited amount of hours in a day to work on your enterprise, wanting to implement selinux is a terrible waste of time and resources that could be MUCH better spent doing almost anything else security related. Stop trying to make SELinux happen. It's not going to happen. Edit: in most server cases, where you have a specific technical staff that are the only ones logging into the server, you don't NEED granular RBAC security controls. It doesn't provide additional benefit from the user level, and, if you're segregating your applications 1 server -> 1 app like you should, it provides no additional benefit from the daemon level either. Bhodi fucked around with this message at 22:51 on Feb 25, 2014 |
|
#
?
Feb 25, 2014 22:44
|
|
|
Bhodi posted:Stop stop stop. For 99% of servers selinux is not only not helpful, but is disadvantageous because of the additional work to administrate. Given a limited amount of hours in a day to work on your enterprise, wanting to implement selinux is a terrible waste of time and resources that could be MUCH better spent doing almost anything else security related. This is exactly the problem, really. SELinux honestly isn't that difficult. And I get that you have better things to do with your time, maybe. But if you're like most enterprises running a relatively homogeneous environment, generating a few sets of policy files for use on your public facing servers is time well spent, and takes literally 10 minutes after you let them run in permissive for a day or so. SELinux is not ongoing administrative overhead. It's set and forget. There is virtually nothing else you can do to effectively stop buffer overflows and privilege escalation from code that's out of your control. Whether that's a concern in your environment is another thing entirely. Bhodi posted:Edit: in most server cases, where you have a specific technical staff that are the only ones logging into the server, you don't NEED granular RBAC security controls. It doesn't provide additional benefit from the user level, and, if you're segregating your applications 1 server -> 1 app like you should, it provides no additional benefit from the daemon level either. evol262 fucked around with this message at 22:54 on Feb 25, 2014 |
|
#
?
Feb 25, 2014 22:52
|
|
|
e: double post
|
|
#
?
Feb 25, 2014 22:54
|
|
|
evol262 posted:UEFI definitely works unless you're on a UEFI 1.something Mac, where isn't really finicky. I can definitively tell you how to fix UEFI when it's broken. It's not all that complex, honestly, until you get into EFI PXE and iSCSI root on EFI and a bunch of other one-offs which rely on bullshit in the tiny, tiny address space available in traditional BIOS and often don't work in EFI at all. Well, more specifically, Gummiboot doesn't work, I think. Everything else (i.e. Grub2 and syslinux) appears to, but for some reason Gummiboot goes mysteriously black after I tell it to boot the Arch installer. Weirdly, it worked the first time after I got SecureBoot to allow vmlinuz to execute, but then never again. Maybe it's possible the firmware is storing some magic "poo poo your pants if you see this executable" setting that isn't cleared by resetting to factory defaults (since resetting demonstrably doesn't clear SecureBoot settings, I assume there are probably other things it doesn't actually reset), but who knows if so or how to clear it, because the only documentation for the specific implementation is stored inside the head of some Chinese developer. The generic Intel documentation that first comes up in Google is essentially "here's a list of commands, one of which will dump the entire contents of NVRAM to screen in octal."
|
|
#
?
Feb 25, 2014 22:54
|
|
|
Stopping buffer overflows and privilege escalation from code that's out of my control is basically RedHat's job when I patch my servers  Sadly, it's really not set and forget, it's set and then set again when my app wants to write to a logfile with a slightly different name, and then set again every release/update of the external facing application because the developers sure as gently caress aren't tracking / packaging selinux bits, plus setting and configuring any time you patch to the latest non-redhat-released rpm to update ruby or python or whatever, I mean you can't even run the vmware tools rpm out of the box directly from vmware until you gently caress around combing permissive log files - ain't nobody got time for that. I think this is a really good example of something that's taught in a classroom verses what's implemented in real life. In a perfect world, the additional security that it provides is advantageous. In the real world, where you have to contrast security with usability, business interests and flexibility, it's simply not viable. Bhodi fucked around with this message at 23:01 on Feb 25, 2014 |
|
#
?
Feb 25, 2014 22:58
|
|
|
The concept of SELinux is fine, and the kernel implementation is solid. It's the userspace tooling and configuration management that's batshit insane.
|
|
#
?
Feb 25, 2014 23:01
|
|
|
Bhodi posted:Sadly, it's really not set and forget, it's set and then set again when my app wants to write to a logfile with a slightly different name Please log to the journal. Thanks.
|
|
#
?
Feb 25, 2014 23:01
|
|
|
Suspicious Dish posted:Please log to the journal. Thanks. Tell that to jboss 
|
|
#
?
Feb 25, 2014 23:02
|
|
|
Bhodi posted:Stop stop stop. For 99% of servers selinux is not only not helpful, but is disadvantageous because of the additional work to administrate. Given a limited amount of hours in a day to work on your enterprise, wanting to implement selinux is a terrible waste of time and resources that could be MUCH better spent doing almost anything else security related. While this was certainly the case in the EL4 days, SELinux has made a lot of progress with various tools and logs and booleans that make typical scenarios a snap. I think the only time in recent memory I've had to get my hands dirty with custom contexts was for veritas volume manager, among other veritas stuff. Everything else is a simple selinux boolean. Like I said, SELinux only has to save your rear end once for it to be worth it. The administrative overhead is minimal nowadays, so it seems like a no brainer to take an hour to figure out the basics instead of just rolling your eyes and turning it off because you don't understand it.
|
|
#
?
Feb 25, 2014 23:02
|
|
|
scroogle nmaps posted:Well, more specifically, Gummiboot doesn't work, I think. Everything else (i.e. Grub2 and syslinux) appears to, but for some reason Gummiboot goes mysteriously black after I tell it to boot the Arch installer. Check "efibootmgr -v" The Arch installer is hopefully signed. So EFI looks for configured bootloaders in nvram (bcfg boot dump -v in the EFI shell). If it can't find any, it boots \EFI\Boot\bootx86.efi (or \bootx64.efi) by default. If it can't find that, it'll dump you to an EFI shell. If it finds a bootloader, it matches the key. I don't know anything about Gummiboot specifically, and the fact that other bootloaders work indicates that you should talk to the Gummiboot devs, as it's probably not an EFI problem. Resetting to factory defaults almost certainly wiped that. You may just have buggy EFI, too.
|
|
#
?
Feb 25, 2014 23:06
|
|
|
Cidrick posted:Like I said, SELinux only has to save your rear end once for it to be worth it. The administrative overhead is minimal nowadays, so it seems like a no brainer to take an hour to figure out the basics instead of just rolling your eyes and turning it off because you don't understand it. Well, I got the RHCE, so technically, I learned it, THEN rolled my eyes and turned it off Honestly - if you're patching regularly (including reboots for kernel updates!), have an IDS with logs that people actually watch, do remote syslogging to a write-once system, and are running Aide/Tripwire, you're pretty much in the 90th percentile already. If you aren't, you should do all those things before you even look at SELinux.
|
|
#
?
Feb 25, 2014 23:07
|
|
|
Bhodi posted:Well, I got the RHCE, so technically, I learned it, THEN rolled my eyes and turned it off Well, sure, SELinux is just one in a long list of good practices to follow in your environment. I suppose I'm just perplexed that you're running into as many issues as you have. Our environment is a mix of EL5 and EL6 but we have over three thousand nodes, and the only place we have SELinux set to permissive is a couple of legacy MySQL DB hosts. Everything else has, for the most part, Just Worked by keeping selinux-policy updated regularly. I very rarely have to do anything other than slap people's hands when they do something silly like moving files where they shouldn't live instead of copying them to keep context inheritance in place. I also do not remember the vmware-tools RPM issues you're talking about, but it's been a couple of years since we set all of those up, and I wasn't actually the one to put the package into our internal repos so I can't say for sure. Edit: as an aside, when you said Tripwire I reflexively shuddered. We replaced that with ossec three years ago and never looked back. I hated tripwire with a flaming passion.
|
|
#
?
Feb 25, 2014 23:16
|
|
|
Bhodi posted:Stopping buffer overflows and privilege escalation from code that's out of my control is basically RedHat's job when I patch my servers Bhodi posted:Sadly, it's really not set and forget, it's set and then set again when my app wants to write to a logfile with a slightly different name Bhodi posted:and then set again every release/update of the external facing application because the developers sure as gently caress aren't tracking / packaging selinux bits Bhodi posted:plus setting and configuring any time you patch to the latest non-redhat-released rpm to update ruby or python or whatever Bhodi posted:I mean you can't even run the vmware tools rpm out of the box directly from vmware until you gently caress around combing permissive log files - ain't nobody got time for that. Is your environment from 2001? Are you automating anything at all? Bhodi posted:I think this is a really good example of something that's taught in a classroom verses what's implemented in real life. In a perfect world, the additional security that it provides is advantageous. In the real world, where you have to contrast security with usability, business interests and flexibility, it's simply not viable. Bhodi posted:Tell that to jboss Don't blame JBoss. Bhodi posted:Honestly - if you're patching regularly (including reboots for kernel updates!), have an IDS with logs that people actually watch, do remote syslogging to a write-once system, and are running Aide/Tripwire, you're pretty much in the 90th percentile already. If you aren't, you should do all those things before you even look at SELinux. [/quote] This is a ridiculous assertion. Having an IDS with logs that people watch, remote syslogging, and Aide/Tripwire may put you in the 90th percentile, but the point of SELinux by default is that your environment is sane out of box, and the time investment in Tripwire is at least as high as SELinux.
|
|
#
?
Feb 25, 2014 23:18
|
|
|
Point by point quoting is somewhat silly in this context! The log stuff I was commenting on are jboss logs and specific app logs created by developers (that can't be logrotated for Reasons outside my control). There are instances that we ran into where, and this is just a random example, devs went in and enabled debugging to figure out performance issues and that wasn't initially captured and permitted. It was after hours, they were unable to get the data they needed, and so I got slammed the next day. There was also a problem getting optier which is this java performance analyzer thing working, because it does some sort of weird memory hook thing. As a company we evaluated it and decided that it was hurting, not helping, the business, and it was a business decision to continue to leave it disabled. Was it the right decision? Who knows. You can always make comments like "Well that's easily fixed in QA" but a lot of the time you have to compromise, negotiate, and work around other groups and people and policies, most of which you don't have control over and are subordinate to. Tripwire/Aide doesn't actually prevent anyone from doing the work right then. That's the biggest difference and in the end the major reason why it was stopped. It isn't just whether or not I could learn it, it's also trying to familiarize everyone who touches the servers and does troubleshooting - like my current T1 Bangladesh team that transposed our database prefix from TS01 to TSO1 on half our servers during an upgrade this weekend and then didn't know what to do when the app wasn't loading (the logs were clear on the issue) and escalated to us with a shrug. I came away from the eval with a personal dislike of selinux but, as Cidrick said, this was probably 4 years ago and more strides have been made to make it usable. Maybe if the eval was done again done today, things would be different. Bhodi fucked around with this message at 23:59 on Feb 25, 2014 |
|
#
?
Feb 25, 2014 23:37
|
|
|
If only we lived in a perfect world and development and operations worked in perfect harmony and we never had to support applications made by outside vendors and there were no business timelines.
|
|
#
?
Feb 26, 2014 03:09
|
|
|
|
| # ? May 9, 2024 21:18 |
|
|
JHVH-1 posted:If only we lived in a perfect world and development and operations worked in perfect harmony and we never had to support applications made by outside vendors and there were no business timelines. The whole point isn't that devs and ops have to work in harmony, it's that you, as an admin, can easily make SELinux work if you don't just write it off. I've also worked under business timelines. I still work under business timelines, supporting outside vendors. Potentially a lot more than you. Not to be all  , but working for a Linux vendor doesn't mean it's all happy Linux stuff. It means that I spend much of my life dealing with OEMs, outside vendors who want their product to work, outside vendors who want to hand off maintenance of their proof-of-concept to my team as a working, ongoing project, and end users who have every imaginable problem. So you get bugs like "iSCSI root on Dell systems with smbios 2.6+ and UEFI fails 30% of the time; please reproduce and fix". It's still not an excuse not to make something work.Bhodi posted:Point by point quoting is somewhat silly in this context! Bhodi posted:The log stuff I was commenting on are jboss logs and specific app logs created by developers (that can't be logrotated for Reasons outside my control). There are instances that we ran into where, and this is just a random example, devs went in and enabled debugging to figure out performance issues and that wasn't initially captured and permitted. It was after hours, they were unable to get the data they needed, and so I got slammed the next day. There was also a problem getting optier which is this java performance analyzer thing working, because it does some sort of weird memory hook thing. Bhodi posted:As a company we evaluated it and decided that it was hurting, not helping, the business, and it was a business decision to continue to leave it disabled. Was it the right decision? Who knows. You can always make comments like "Well that's easily fixed in QA" but a lot of the time you have to compromise, negotiate, and work around other groups and people and policies, most of which you don't have control over and are subordinate to. I know that's not often palatable to management, and development hates doing it because they don't know if they'll be able to reproduce, and they often rule the roost. And SELinux is harmful in this situation. But that situation is painful no matter how you cut it, and more so when your team doesn't have enough oomph or political capital to push back and say "no, we're not doing this, roll back and development can deal with it on Monday", which always would have been my response, but I guess I was the kind of admin who wanted my servers to run properly. Development can have as much assistance from me as they want in dev/QA, but when you want to attach a debugger to production?  Bhodi posted:Tripwire/Aide doesn't actually prevent anyone from doing the work right then. That's the biggest difference and in the end the major reason why it was stopped. It isn't just whether or not I could learn it, it's also trying to familiarize everyone who touches the servers and does troubleshooting - like my current T1 Bangladesh team that transposed our database prefix from TS01 to TSO1 on half our servers during an upgrade this weekend and then didn't know what to do when the app wasn't loading (the logs were clear on the issue) and escalated to us with a shrug.
|
|
#
?
Feb 26, 2014 04:04
|
|