Alpha01's questions

Environment:

• CentOS 6.8
• PHP 5.6.5 (installed via Software Collections)

I'm getting the following error when trying to install imagick:

[root@vm ~]# pecl install imagick
No releases for package "pecl/imagick" exist
install failed

I'm able to successfully install other extensions perfectly fine, except for imagick. I've already tried updating all channels/purged cache and still no luck.

A strange thing is that I'm able to view the extension, but it won't show the "Latest" version of it.

[root@vm ~]# pecl remote-info imagick
Package details:
================
Latest
Installed   - no -
Package     imagick
License     PHP License
Category    Images
Summary     Provides a wrapper to the ImageMagick library.
Description Imagick is a native php extension to create and
            modify images using the ImageMagick API.
            This extension requires ImageMagick version
            6.5.3-10+ and PHP 5.4.0+.

Any one have any ideas on why I can't install the imagick extension? This wasn't a problem a few months ago.

Does anyone know if Nagios has an option to set a temporary check_interval setting on a service check and have it revert back after a X minutes?

My service check definition looks like this:

define service {
    host_name prodhost
    use http
    service_description www.example.com:8080
    check_command check_http!8080!example.com:8080!/!5.000!10.00
    servicegroups http-check
    check_interval .5
    retry_interval .25
    max_check_attempts 3

}

The problem is that each time changes are made onto my web app (via a CI), it also has to restart the application as part of the deployment process. Which triggers some of my 5 second and 10 second warning and critical alerts.

I would like to be able to keep my current check_interval, retry_interval, and max_check_attempts thresholds in tact, but be able to temporarily change them whenever a deployment is made and have it revert back to its original state after 3 minutes.

I'm trying to do some file system checks using LVM snapshots of our Logical Volumes to see if any of them have dirty file systems.

The problem that I have is that our LVM only has one Volume Group with no available space. I was able to do fsck's on some of the logical volumes using a loopback file system. However my question is, is it possible to create a 200GB loopback file system, and saved it on the same partition/logical volume that I'll be taking a snapshot of? Is LVM smart enough to not take a snapshot copy of the actual snapshot?

[root@server z]# vgdisplay
--- Volume group ---
VG Name               Web2-Vol
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No  29
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                6
Open LV               6
Max PV                0
Cur PV                1
Act PV                1
VG Size               544.73 GB
PE Size               4.00 MB
Total PE              139450
Alloc PE / Size       139450 / 544.73 GB
Free  PE / Size       0 / 0
VG UUID               BrVwNz-h1IO-ZETA-MeIf-1yq7-fHpn-fwMTcV


[root@server z]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             9.7G  3.6G  5.6G  40% /
/dev/sda1             251M   29M  210M  12% /boot
/dev/mapper/Web2--Vol-var
                       12G  1.1G   11G  10% /var
/dev/mapper/Web2--Vol-var--spool
                   12G  184M   12G   2% /var/spool
/dev/mapper/Web2--Vol-var--lib--mysql
                   30G   15G   14G  52% /var/lib/mysql
/dev/mapper/Web2--Vol-usr
                   13G  3.3G  8.9G  27% /usr
/dev/mapper/Web2--Vol-z
                  468G  197G  267G  43% /z
/dev/mapper/Web2--Vol-tmp
                  3.0G   76M  2.8G   3% /tmp
tmpfs                 7.9G   92K  7.9G   1% /dev/shm

The logical volume in question is /dev/mapper/Web2--Vol-z. I'm afraid if I created the loopback file system in /dev/mapper/Web2--Vol-z and take a snapshot of it, the disk size will be trippled in size, thus running out of disk space available.

Does anyone know of a utility of that would give me the total number of email messages sent by sendmail, using old maillogs ?

Someone suggested the use of the mailstats utility, however this program seems to give the statistical information for all mail log file entries. Though this is beneficial, it's not helpful on this case since a single mail message sent by sendmail can log anywhere to 5 different log entries.

I've been thinking of enabling process accounting on a production server as a proactive security measure to monitor what's being ran on the system.

Looking at the initial documentation it appears that enabling process accounting on a busy system might result in a significant amount of disk space being used to log and store the system process information.

Anyone know what are the best recommendations on enabling process monitoring? Also any considerations on the setup, especially since this is a production server.

Ideally, I'd just want to log any shell commands including PHP exec(), system(), passthru(). etc..

-Tony

I just noticed a weird directories stored on both in /tmp within two of my CentOS boxes.

On one machine the temp directory is called /tmp/www4-679109 while on my second machine the temp directory is /tmp/sos_e6X9_3.

Both of these suspicious directories contain four subdirectories: etc proc sys var .

The etc folder on this suspicious directory tree contains an identical copy of my master submit.cf sendmail configuration file. /tmp/sos_e6X9_3/etc/mail/submit.cf and /etc/mail/submit.cf. This makes me think that some how sendmail was used to relay mail. Though I can't verify the maillog files were inconclusive is this was the case.

Also this suspecious wierd directory contains some sort of audit log files within it. (/tmp/sos_e6X9_3/var/log/audit/audit.log.1)

Snippet of contents of a log file:

type=LOGIN msg=audit(1293719401.416:2772543): login pid=6662 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=557197
type=LOGIN msg=audit(1293719401.417:2772544): login pid=6660 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=557198
type=LOGIN msg=audit(1293719401.418:2772545): login pid=6649 uid=0 old auid=4294967295 new auid=599 old ses=4294967295 new ses=557199
type=LOGIN msg=audit(1293719401.420:2772546): login pid=6665 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=557200
type=USER_ACCT msg=audit(1293719401.423:2772547): user pid=6668 uid=0 auid=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='PAM: accounting acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'
type=USER_START msg=audit(1293719401.424:2772548): user pid=6653 uid=0 auid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='PAM: session open acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'

What is concerning me more with this suspicious files and directories on my CentOS boxes is that it appears that their is a procfs like directory in /tmp/sos_e6X9_3/proc. The only difference with /tmp/sos_e6X9_3/proc and /proc is that in the /tmp/sos_e6X9_3/proc there aren't any viewable process information.

I have kept both CentOS machines up to date and did not make any change to sendmail that would somewhow make it vulnerable, (unless sendmail is vulnerable right off the box).

Does anyone have have any ideas/feedback on why these suspicious temp files and folders were created?

UPDATE: It appears that the suspicious files were generated by the sosreport utility when we were working with Red Hat support on a different issue. I checked the log and the timestamps match with the timestamp with the suspicious files and directories. Thanks for your support and feedback. You guys rock!