Archive for April, 2013

Run JVisualVM against another user’s process

10 years
by in Uncategorized

Suppose you’re a good admin and you run JBoss as it’s own user rather than as root or yourself, but your devs need to use VisualVM- How do you give them access without providing ssh access to jboss or setting up jstat? Today I figured out I could do this:

First, install the required packages to forward X11 traffic:

  yum install xorg-x11-xauth libXtst

Once that’s in place, make sure that you have the following in your server’s sshd_config:

  X11Forwarding yes
  AllowTcpForwarding yes

And in sudoers, make sure you have:

Defaults env_keep += "DISPLAY XAUTHORITY XAUTHORIZATION"

The final step is to use some Xauth voodoo. I wrote this handy wrapper script to bottle up the changes:

#!/bin/bash
MYID=`/usr/bin/xauth list|head -n 1|awk '{print $1}'`
/usr/bin/xauth extract - ${MYID} |/usr/bin/sudo -u jboss -H /usr/bin/xauth merge -
cd /tmp/
/usr/bin/sudo -u jboss -H -E /usr/java/latest/bin/jvisualvm

And as long as your users have the proper sudo access to the jboss user, you should be all set.

Let me know if this was useful.

Puppet Training Notes from Day 3.

10 years
by in Uncategorized

Final notes from day 3:

  1. Using an External Node Classifier(ENC) is considered best practice over site.pp
  2. There is a  “puppet visual index” that has useful examples
  3. You can use ~> and -> to chain dependencies to help make things more readable.
  4. If I can figure out how to integrate it, I could use LDAP inventory tags to indicate puppet classes
  5. Hiera can be used to extract out data from configs
  6. Once data is abstracted out, I can put them on github and puppetforge
  7. the config_version parameter can be used to control the format of the puppet version (using date command, for example)
  8. There is a style guide available for puppet- it’s what puppet-lint uses.
  9. there is a vim-puppet plugin on github, however it’s currently broken in apt on ubuntu
  10. syntastic may be worth checking into to make vim a better IDE
  11. I really need to reconfigure ctags for perl.
  12. I should use case default: { fail(“this ${module_name} isn’t supported here”)} for better errors on case statements
  13. ask.puppetlabs.comn is a great resource when IRC fails me.
  14. I can use rspec with puppet to do TDD. This sounds very promising.
  15. Certification is $200, however I get get a 25% discount. I should be able to pass this.
  16. If puppet dashboard is slow, clean out old reports.
  17. Consider signing up for the test pilot program.

Puppet Training Notes from Day 2.

10 years
by in Uncategorized

 Notes from Day 2:

  1. subscribe is the other side of notify the same way require is for before.
  2. In puppet.conf, under [agent] set graph=true for previously mentioned dot file creation.
  3. I need to take a look at concat, file_line and augeas.
  4. Use puppet parser validate init.pp to quick validate syntax.
  5. audit=>’content’ will track changes, even if puppet doesn’t care what it is.
  6. Setting default values in a class can drastically reduce manifest size.
  7. Use ${::hostname} to access the fact hostname rather than a potentially overridden local value.
  8. Use path=>’blah‘ more to make exec command easier to read;
  9. You can test fact conditionals with FACTER_operatingsystem=Debian puppet apply ../tests/init.pp.
  10. check out vagrant, looks useful.
  11. You can use rubular to test regexes.
  12. There is a presentation on using “profiles and roles” design pattern that’s worth rereading
  13. Profiles can be treated as a collection of modules.
  14. razor server is the provisioning tool that Joe mentioned, but it’s not ready for prod usage.
  15. We can define a new resource type for vhosts and define them individually. I need to keep an eye out for other uses.

Puppet Training Notes from Day 1.

10 years
by in Uncategorized

I am currently in a training class for Puppet, which is a configuration management tool that I use at work. Yesterday was the first day, and here were the things I’ve learned so far:

 

  1. Puppet can actually create a dependency graph to visualize class relationships. By enabling “graph” in one of the configs, it will produce a .dot file for each host showing their dependency tree.
  2. Facter can almost single-handedly replace my linux_inventory.sh script, and do it more consistently and flexibly. The output is yaml, but it’s easy to translate to LDIF.
  3. Using “environments” is far easier than I thought and something I can implement almost immediately. This can feed off the priority number in our hostnames.
  4. I can set up puppet-dashboard to be an external node classifier, meaning I no longer need a massive, ugly site.pp file.
  5. Puppet-lint can be used to test puppet syntax not only for correctness, but for best-practice formatting. I need to add this to my workflow.
  6. The external_node mentioned in the terminus config line is a script, and I can manually use it to see which classes are applied to which hosts.
  7. My current dashboard is ungodly slow, so I need to re-implement it with a proper container.
  8. The Enterprise version of puppet can handle certificate signing right in the interface, which is pretty handy and way more user-friendly.
  9. The puppet cert –clean command is the proper way to remove an old cert for a host that has been re-imaged.
  10. Puppet can integrate with Splunk to feed it its reports, allowing you to correlate puppet events with Splunk events.
  11. host resource can get rid of ugly hosts file manipulation.
  12. You can set user resource to remove all non-system accounts to ensure no sneaky backdoor accounts are set up.
  13. Schedule can be used to run tasks if the run happens in the specified timeframe (Edit: thanks for the better description zipkid).
  14. Exported resources can be used to export data, which can then be imported into Icinga, even further reducing the need for “dynamic detection” on Icinga configuration generation scripts.

So as you can see, a lot of good stuff.

Go to Top