1 / 64

Unix Linux Administration III

Unix Linux Administration III. Class 6: Perl subroutines. Nagios configuration. Custom Nagios monitors. Agenda. Review lecture from week 4. Discuss lecture from week 5 Python Puppet Review homework Findutils and NTP IPF the Solaris firewall Perl subroutines. Review: GNU tools and NTP.

Download Presentation

Unix Linux Administration III

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Unix Linux Administration III Class 6: Perl subroutines. Nagios configuration. Custom Nagios monitors.

  2. Agenda • Review lecture from week 4. • Discuss lecture from week 5 • Python • Puppet • Review homework • Findutils and NTP • IPF the Solaris firewall • Perl subroutines.

  3. Review: GNU tools and NTP. Locate and updatedb can be installed quickly using openCSW. sudo resets environment variables but they can be maintained if defined in the sudoers file. NTP is not enabled by default but sample configs exist and the setup is fairly simple.

  4. Review: IPF • IPF provides packet filtering by IP, port, protocol, network interface, and traffic direction. • supports NAT, PAT and stateful packet inspection. • managed using SMF (svcadm disable|enable pfil|ipfilter) svcs -x ipfilter • configurations stored in text files under /etc/pfil/. These are read in at boot or when the service is restarted. • utilities include, ipf, ipfs, ipfstat, ipmon, ipnat, ippool. • basic firewall syntax: action, direction, packet • block in from <address> to <address> all • Rules read from top to bottom, LAST match is applied. default ALLOW. • Exceptions to this rule for keywords quick and group.

  5. Q3, Class 4, Unit 3 What we are going to cover: • The Perl subroutines. What you should leave this session with: • How subroutines allow you to reuse code • Perl pragmas

  6. Perl: subroutines Subroutines = user defined functions. Subroutines are identified with an ampersand (The & is usually optional). Just as we saw with Scalars ($) and Arrays (@), subroutines (&) can have the same name as one of these other variables without conflicting. However; this is may be confusing.

  7. Subroutines: user defined functions Just like subroutines in other languages; a subroutine allows for the reuse of code in your script. Format: sub subroutine_name { statements; }; sub say_hello { print “Hello World\n”;};

  8. Placing your subroutine Your sub can be anywhere in the script, location is unimportant. I tend to place my at the bottom of my scripts. If you have two subs with the same name in the same script, the last one wins. But if you have warning enabled you would be notified.

  9. Calling all subs Ways you can invoke or call your subroutine. Add () to the end of the expression sub_routine(); $value = sub_routine(); &sub_routine; Older versions of perl may support do sub_routine but this has been depreciated.

  10. Return Values All subs have return values; the value of the return is variable. The return value of the subroutine is either the value of the last expression or the value specifically returned return ($value) Functions can also return arrays of values return (@array) return ($a, $b, $c);

  11. Arguments Arguments are passed to subroutine as one array (@_)* @_ is a private variable to the subroutine new private values are created for each subroutine. Global values stored in @_ are restored after the subroutine is complete. *Similar to $_

  12. Passing arguments To pass a value to subroutine place it in the parentheses after the invocation. my $day; update ( "monday" ); sub update { ($day) = @_; print "Hello, your appt is on: $day\n"; }

  13. Private Variables in Functions Normally variables are global in nature Use the *my() command to create local instances of variables that only exist inside the subroutine my @array = @_; my ($counter, $sum) = @array; Only available inside this subroutine, not available to nested subroutines *We will discuss my and strict later in the lecture.

  14. Variable length parameter lists Subroutines are often invoked with a variable list of parameters. This is by design as Perl attempts to place “no unnecessary limits” on the user. However; you can test for the length if you want. if (@_ != 5) { print “Error, requires 5 arguments\n”; } But this is rarely used or needed.

  15. High water mark $highest = max ( 2, 6, 4, 9, 3); sub max { my($max_so_far) = shift @_; foreach (@_) { if ( $_ > $max_so_far ) { $max_so_far = $_; } } $max_so_far; # tracks high water value. }

  16. Defining the return value Using the return operator will immediately return a value from the subroutine. You may find code where every subroutine includes a return statement. This is a reasonable way to document what the expected return value should be.

  17. When to use the & If Perl can determine from the context that you are referencing a subroutine the & is not required. But, if there is a Perl built-in function with the same name as your subroutine you must use the &. So when in doubt use the &

  18. Persistent, private variables Using “my” we make variables private to the subroutine sub sand { my ($top1, $top2, $top3,) = @_; } If we use “state” we can retain the values of $top1, 2 and 3 between calls to the subroutine. Using state requires Perl 5.10 which we do NOT have by default.

  19. Basic subroutine sample my $n; count(); count(2); sub count { $n = shift @_; $n += 1; print "found number: $n\n"; }

  20. Perl pragma A Perl pragma is a chunk of code that attempts to provide hints to the complier about the code. Pragmas are specific code that you can embed in your code causing your scripts to potentially behave differently. “warnings” is a pragma that will provide feedback when there are potential issues or errors found in your perl code. Pragmas are defined towards the top of your script. #!/usr/bin/perl use warnings;

  21. Using the “strict” pragma Perl is a very loose language by default. It is often faulted for this (note Obfuscated Perl contests in days past). Using strict attempts to enforce good coding standards. “use strict;” should be enabled in most if not all your Perl scripts. Some things strict enforces: • declared variables • strings to be quoted #!/usr/bin/perl use strict; use warnings;

  22. When using my variables Private variable are scoped to the smallest enclosing block or file. Using my with () parentheses scopes the impact. my $user, $credential; # only declares $user my ($user, $credential); # declares both The my function is provided by the “strict” pragma.

  23. CGI pragma As mentioned before CGI or Common Gateway Interface is a standard of communication between a web server and a client. Perl provides a CGI focused pragma. This module provides lots of web service related functionality within Perl. The Perl CGI module supports both standard function format coding and object oriented scripting. Object Oriented (OO) sample next.

  24. CGI “hello world” using Perl OO #!/usr/bin/perl use strict; use CGI; my $cgi = new CGI; print $cgi->header; print $cgi->start_html("Hello World"); print $cgi->h1("Hello World"); print $cgi->end_html(); exit;

  25. Review • subroutines - user defined functions. • subroutines identified using the ampersand & sub subroutine_name { statements; }; sub say_hello { print "hello, world\n"; }; • subroutines can be placed anywhere in the script. • all subs return values, some are undef. • arguments passed as one array (@_) • use my to create local instances of variables. • perl pragmas provide additional functionality. common examples include warnings, strict and cgi. • The CGI module provides many web service related functions and supports OO scripting.

  26. In class lab 5a • Lab notes for this session can be found here: http://www.ulcert.uw.edu -> Class Content -> InClass labs ->

  27. Q3, Class 5, Unit 2 What we are going to cover: • Nagios configurations. What you should leave this session with: • The relationship between objects. • How to customize your Nagios install.

  28. Nagios monitoring Remember there are two types of monitoring: System monitoring and Network monitoring. System monitoring is limited to local stats but network monitoring will test services both local and remote.

  29. Primary Nagios components The service is manged by a daemon, the Nagios daemon. This process provids the webinterface and runs the various checks. The Nagios plug-ins are a collection of scripts used for checking various services.

  30. Primary configuration files. The three primary configuration files are: • nagios.cfg • cgi.cfg • resources.cfg

  31. Primary config nagios.cfg <nagroot>/etc/nagios.cfg This file is read by nagios every time it is started up. Lots of options are defined within this file including resources (variables), configuration locations, object definitions, etc. we can verify the nagios.conf file using: <nagroot>/bin/nagios –v <nagroot>/etc/nagios.cfg

  32. Nagios cgi.cfg The web interface for Nagios is based on a cgi.cfg which can be found under /usr/local/nagios/etc/ This file is not referenced in the primary nagios.cfg file but rather by the config.inc.php found under /usr/local/nagios/share. This directory is defined in the /etc/httpd/conf.d/nagios.conf web config. This is one file that is NOT defined in the primary nagios.cfg.

  33. resources.cfg Nagios expects to find the definition of Macros in this file. The location of this file is defined by nagios.cf By default we find the value for $USER1$ here. $USER1$=/usr/local/nagios/libexec Nagios supports upto 32 of these macros which can be customized for your needs.

  34. Configuration layout By default the <nagroot>/etc/nagios.cfg file defines each individual cf file location but it can be configured to support configuration directories. Using this standard nagios will look under that directory for any files ending in cfg. This allows you to consider groupings by site, hosts, application or any other configuration that makes sense for you.

  35. Nagios layout suggestions. By environment; dev, qa, prod: /usr/local/nagios/etc/prod /qa /dev Or by platform /usr/local/nagios/etc/linux services hosts host1 /usr/local/nagios/etc/windows services hosts host1

  36. Objects Objects in nagios define a host, a service, a contact or a group to which each belongs. Actually even commands are objects. object definitions configurations are: define object-type { parameter value parameter value ... } for example define host{ host_name q2.books.ulcert.uw.edu alias Q2 Books ULCert server

  37. Host objects A host object provides a mapping between a IP address and a name. As earlier noted the location of these files is configurable. By default object files are stored under <nagroot>/etc/nagios/objects required values include: host_name, alias, address, max_check_attempts, check_period, contact_groups, notification_interval, notification_period, notification_options.

  38. Service objects define service { host_name service_description ... A service always consists of a host and a service name. This combination must be unique. The service does not have to be unique. required values include: host_name, service_description, check_command, max_check_attempts, normal_check_interval, check_period, notification_interval, notification_period, notification_options, contact_groups. The ping service is very simple; as it just checks to see if a host is reachable (via icmp).

  39. Contact objects contacts define who will be notified in the case of an event. The contact is also related to the web authentication. The user will only be able to see hosts and services for which that user is defined as a contacts

  40. Command objects All the available commands are defined in well the commands.cf file. Nagios includes a sample of these objects based on the installed plugins but more are available. All the available commands are defined in well the commands.cf file check_ping is a simple and common Nagios command. The interesting thing about check_ping is its use as both a host check and a service check. This is different than say the http or ftp checks which are purely service checks.

  41. commands.cfg and macros As you review the commands.cfg file you will note the use of $ signs. Identifiers surrounded by $ signs are actually macros. Nagios uses three types of macros. • First there are $USERX$ where X can be a value from 1 to 32. The value of these variables are defined in the resources.cf file. $USER1$ resolves to the plugin directory. • The second macro type is the arguments. These can be passed when a command is executed. These include $ARG1$, $ARG2$ • The third macro group is $HOSTADDRESS$ which resolves to the IP address of the host in the host definition

  42. macros cont. Before Nagios executes a command it will replace any macro with the corresponding value or values. Macros allow you to reference information from hosts, services and other sources in your commands. You can create custom macros.

  43. Understanding check_ping # 'check_ping' command definition define command{ command_name check_ping command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5 } From the a localhost.cf. check_command check_ping!100.0,20%!500.0,60% In this example we see that command and the arguments are separated by an exclamation (!) The $ARGX$ define the warning and errors thresholds respectively. A 100 millisecond response time and 20% loss triggers a warning. A 500 millisecond response and 60% loss triggers a critical alert.

  44. Templates Templates allow for features to be inherited by other objects. The key directives in a template are the name and the register value. If the register value is set to "0" then it is template and nagios will not treat this as a real object. By default all templates are defined in the templates.cf file; however, this is not required. Templates can exist in your object based files. There are templates definitions for contacts, hosts, and services objects.

  45. Contacts and notifications When things change on your network that Nagios monitors you will be informed based on the notifications defined for that object. Check the contact.cf for contact groups Contact options include email, SMS messages, pagers and anything else you care to configure Timeperiods.cf defines just what you might expect.

  46. Sample host definition. This is a sample host config, much of the object is inherited from the template. define host{ use linux-server ; host template host_name q3.books.ulcert.uw.edu ; comment alias "Q3 sun server"; address 172.22.159.155 ; }

  47. Sample host check Review the localhost.cfg for sample configs This is a sample ping test define service{ use local-service ;service template host_name localhost service_description PING check_command check_ping! 100.0,20%!500.0,60% }

  48. Update, test config and reload Once you have a new config in place update your nagios.cf file to reflect the new object if necessary. New files under cf_dir=/usr/local/nagios/etc/conf.d do not need an explicit definition. Test your new configuration /usr/local/nagios/bin/nagios –v nagios.cfg Restart nagios /sbin/service nagios restart Check the web admin for the new object.

  49. Review: nagios configuration Two types of monitoring, system and network Two components; nagios daemon and plugins. Three primary config files nagios.cfg cgi.cfg resources.cfg lLyout based on environment, applications, platform or something else.. Objects define hosts, services, contacts and even commands. Macros used extensively in Nagios. macros can be customized. Templates used to simplfy configurations and for inheritenance. Test your config /usr/local/nagios/bin/nagios –v nagios.cfg Restart nagios service nagios restart

  50. In class lab 5b • Lab notes for this session can be found here: http://www.ulcert.uw.edu -> Class Content -> InClass labs ->

More Related