Subscribe to this blog     
КатегорииLinksUnix Tutorial
Personal Development Ruslan Valiev Solaris Performance Team Damien Farnham Fintan Ryan Nicky Veitch Niall Mullen Sean McGrath DTrace Bryan Cantrill Brendan Gregg ZFS Tim Foster General Ben Rockwood Learning Solaris 10 Privacy policy |
Friday, November 9. 2007
Announcing a new website: DTrace Scripts Posted by Gleb Reys
in DTrace at
14:53
Comments (0) Trackbacks (0) Announcing a new website: DTrace Scripts
Thanks to CurThread.org, I've recently learned about the new online project which just got started: DTrace Scripts. It seems to be a promising project with a constantly expanding collection of DTrace scripts and tips, and it's great to see yet another project aimed at making DTrace more accessible and better known in Unix communities.
Wednesday, February 8. 2006Another good article on DTrace
Thanks to Adam Leventhal, who is one of DTrace authors, I've learned about the recent article on DTrace by Bryan Cantrill.
I liked this article a lot, so it's been immediately added to my Useful DTrace resources index. You can read the article by following this link: Hidden in Plain Sight Friday, January 27. 2006Useful resources on DTrace
I've finally found time to start yet another good tradition on my blog. From now on, I'll maintain an index of links to all my articles on DTrace, which will also include links to all other resources on DTrace I've found useful.
This link repositary can be found at the following URL: http://solaris.reys.net/english/dtrace Wednesday, December 21. 2005
DTrace: playing with mod_auth_pam ... Posted by Gleb Reys
in DTrace at
13:29
Comments (12) Trackbacks (0) DTrace: playing with mod_auth_pam and Apache 2
One of our users has asked me to help with PAM authentication for Apache 2 on one of our remote servers.
It did seem like a rather trivial task - download mod_auth_pam, compile it for Apache 2, make sure everything works. The remote server uses NIS, I could freely log onto it. And you know what? It didn't work. The module compiled pretty easy, but I couldn't get it to work - error_log was reporting the same lines over and over again (I had to break the line to squeeze it into my blog format): CODE: [Tue Dec 20 16:48:44 2005] [error] [client xxx.xxx.xxx.xxx] \ PAM: user 'greys' - not authenticated: No account present for user Up to this point, everything was done by the user himself with small help from me. At this stage is was decided I'd have a look myself. To make things easier, I also wanted to: 1) Move all the experiments onto my own Solaris 10 box 2) Make it all work for local users first, and only then get NIS working as well Seeing the same errors on my box, I've decided to take a serious look at PAM. I've created Apache-related lines in /etc/pam.conf and added a debug option: CODE: httpd auth required pam_authtok_get.so.1 debug httpd auth required pam_unix_auth.so.1 debug To make it more convenient to track all the messages, I've updated /etc/syslog.conf to include the following: CODE: auth.debug /var/log/auth_log user.debug /var/log/user_log It got easier to see what was happening, at least I knew it was the /etc/pam.conf section I was thinking of. But the error was still there - my user definitely did exist in the system, only it wouldn't be recognized by Apache (and I've broken the lines yet again here): CODE: Dec 21 09:47:35 pele httpd[29143]: [ID 634615 user.debug] \ pam_authtok_get:pam_sm_authenticate: flags = 1 Dec 21 09:47:35 pele httpd[29143]: [ID 378613 user.debug] \ pam_dhkeys: user greys not found Dec 21 09:47:35 pele httpd[29143]: [ID 896952 user.debug] \ pam_unix_auth: entering pam_sm_authenticate() Dec 21 09:47:35 pele httpd[29143]: [ID 219349 user.debug] \ pam_unix_auth: user greys not found It was the right time to look at how exactly PAM and Apache 2 interacted when I was giving the username and password trying to access my page. I immediately thought of Brendan Gregg's opensnoop script for DTrace. And it was this script indeed which helped me see the problem: CODE: 60001 24744 httpd -1 2 /etc/pam_debug 60001 24744 httpd 11 0 /etc/pam.conf 60001 24744 httpd 11 0 /usr/lib/security/pam_authtok_get.so.1 60001 24744 httpd 11 0 /usr/lib/passwdutil.so.1 60001 24744 httpd 11 0 /usr/lib/libsldap.so.1 60001 24744 httpd 11 0 /usr/lib/security/pam_dhkeys.so.1 60001 24744 httpd 11 0 /usr/lib/security/pam_unix_cred.so.1 60001 24744 httpd 11 0 /lib/libbsm.so.1 60001 24744 httpd 11 0 /lib/libsecdb.so.1 60001 24744 httpd 11 0 /usr/lib/libproject.so.1 60001 24744 httpd 11 0 /lib/libproc.so.1 60001 24744 httpd 11 0 /lib/librtld_db.so.1 60001 24744 httpd 11 0 /lib/libelf.so.1 60001 24744 httpd 11 0 /lib/libctf.so.1 60001 24744 httpd 11 0 /usr/lib/security/pam_unix_auth.so.1 60001 24744 httpd -1 2 /var/run/syslog_door 60001 24744 httpd -1 13 /etc/shadow 60001 24744 httpd 11 0 /var/run/name_service_door 60001 24744 httpd 11 0 /etc/passwd 60001 24744 httpd -1 13 /etc/shadow 60001 24744 httpd -1 2 /var/run/syslog_door Apparently, httpd could not open /etc/shadow (-1 means error), obviously becase of permissions for the file. But just to make sure, I've looked for the error code (it's 13 as you can see): CODE: bash-3.00# grep 13 /usr/include/sys/errno.h #define EACCES 13 /* Permission denied */ So it all was suddenly clear, and I've proceeded like this: CODE: #groupadd shadows # chown root:shadows /etc/shadow # chmod 440 /etc/shadow All that's left to be done now was to make sure httpd.conf has a Group parameter set to this shadows group, and not nobody. pS: you might ask why didn't it work for NIS on the remote server in first place. This is because /etc/nsswitch.conf had not this: passwd: files nis, but this: passwd: compat, so NIS maps were consulted, but only based on + and - specifications in /etc/passwd and /etc/shadow files. This means we still needed to be able to read /etc/shadow, even though later PAM would consult NIS. Tuesday, December 13. 2005DTrace: observing PHP, part 2
Your next step in observing PHP with DTrace could easily be the following script. It times how much time (in nanoseconds) each Apache process has spent running a particular PHP function.
This script generates a table of Apache PIDs and PHP scripts started within, and later you'll get a table of all the functions with PIDs which ran them and the time spent. You can download this script here: php-scripts-timer.d CODE: #!/usr/sbin/dtrace -s #pragma D option quiet BEGIN { printf("php scripts timer started\n"); } :dtrace.so::function-entry / copyinstr(arg0) == "" && name[pid,copyinstr(arg1)] != 1 / { printf("%d -> %-30s\n", pid, copyinstr(arg1)); name[pid,copyinstr(arg1)] = 1; } :dtrace.so::function-entry / copyinstr(arg0) != "" / { self->ts = timestamp; } :dtrace.so::function-return / copyinstr(arg0) != "" / { self->elapsed = timestamp - self->ts; @time[pid, copyinstr(arg0)] = sum(self->elapsed); } END { printf("<------ php scripts timer finished"); printf("\n%10s %40s %14s\n", "PID", "PHP function", "Time elapsed"); printa("%10d %40s %14@u\n", @time); } A typical result of running this script while opening some PHP pages served by your Apache will look like this: CODE: php scripts timer started
223074 -> /export/www/nightly/pma/left.php 223071 -> /export/www/nightly/pma/main.php 223074 -> /export/www/nightly/pma/css/phpmyadmin.css.php 223071 -> /export/www/nightly/pma/css/phpmyadmin.css.php <------ php scripts timer finished PID PHP function Time elapsed 223074 ob_get_level 22280 223074 get_cfg_var 32678 223074 mysql_get_client_info 32705 223074 strrpos 39160 223074 PMA_auth_set_user 39178 223071 get_magic_quotes_gpc 39478 223071 ob_get_level 43673 223071 addslashes 54847 223074 strpos 56869 223071 basename 61874 223071 PMA_reloadNavigation 63588 223071 mysql_get_client_info 64570 223071 get_cfg_var 64592 223071 ereg_replace 65993 223074 get_magic_quotes_gpc 67738 ... 234950 main 84254684 238255 main 105016748 238255 substr 153752861 238255 mysql_query 192585647 238255 PMA_DBI_try_query 195113800 234950 PMA_DBI_query 220108343 234950 mysql_query 276732073 234950 PMA_DBI_try_query 280801228 |