page_title: Dropbox-2016-02-08 page_touched: 20160212193848 old_text: ===Monday===

  • Clean up dropbox-corp-dhcp package with omapi-control in it. Add support for included files.

===Tuesday===

  • CorpSRE team meeting
  • Set passwords on ipmi systems in SFO, store the passwords in 1password

===Thursday===

  • Look for iDRACs in splunk. Only SFO has host names that end in ipmi.
  • XSS scripting counter measures at Dropbox
  • Chef kick off
  • Create client certificate for use against the ldap test servers following instructions at https://jamielinux.com/docs/openssl-certificate-authority/
  • Try and make a client connection and still fail.

===Friday=== * Read openldap list ** Interesting post about selinux debugging

The standard procedure I use to debug SELinux issues and then create SELinux rule files to allow previosuly forbidden interactions is the following (all steps as root). Don’t trust anyone or any advice from random websites that tell you to just switch off SELinux to make things work, those people obviously don’t know anything about the topic at all.
  1. Switch from Enforcing to Permissive mode so everything is allowed but still fully logged: 
            setenforce permissive
  2. Run through your test scenarios, like starting and stopping all the involved system services and logging in/using your applications
  3. Get a report using audit2allow: 
            audit2allow -al
    Now you have a report showing you what’s disallowed and what processes are involved.
  4. To create a policy file that can be loaded into the SELinux rule set in order to prevent the denials you create a type enforcement rule file (you can choose any name for it that does not collide with built-in policies): 
            audit2allow -alm my_custom_policy_name >my_custom_policy_name.te
  5. Now you compile it into a format the kernel understands: 
            checkmodule -M -m -o my_custom_policy_name.mod my_custom_policy_name.te
        semodule_package -o my_custom_policy_name.pp -m my_custom_policy_name.mod
  6. Insert the compiled module (the .pp file) into the SELinux rule set: 
            semodule -u my_custom_policy_name.pp
  7. Now test again (return to step 2) and if there are any remaining issues follow steps 3-7. IMPORTANT: If you create a new policy file in step 4, make sure to INCREMENT the version number that’s shown at the top of the file. If your new policy retains the old policy version number it will not load.
  8. Once you’re happy do not forget to return to enforcing mode: 
            setenforce enforcing
  • Moved user VMs to deleted folder and update notes in vCenter
  • Land reservations of ipmi addresses for dublin
  • Added cnames for sfo esxi systems and dub new esxi/netsrv systems

?DropboxLogs 390. row