[Aide] AIDE configuration taking too long

[Mason Nakadomari]

Hi my organization is not satisfied with the deafult aide configuration. We
want to look at all the files in the root file system without excluding
directories for security reasons. We know that certain directories will
only be checked for certain attributes for example log files would not have
mtime checked. However I have run a few configurations below scanning the
whole root to see what attributes we can whittle down to produce a more
efficient configuration and its taking an enormous amount of time.
I'm using the below configuration.
CUSTOMTEST1=p+i+u+g+m+acl+selinux+md5
CUSTOMTEST2=p+i+u+g+s+n+m+acl+selinux
These are on rhel 6 servers this is scanning the whole root.
so for example
@@ifhost test77
/ CUSTOMTEST1
@@ifhost test77
[root at aid70 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg0-lvroot
48G 3.1G 42G 7% /
tmpfs 937M 0 937M 0% /dev/shm
/dev/sda1 1007M 67M 890M 7% /boot

The CUSTOMTEST1 config on aide.init continues to run after 3 days.
The CUSTOMTEST2 config has been running for more than 30 hours.

We figured that the removal of a checksum would help performance but both
are taking extremely long.
Are we butting heads with something in the file system. Is it impossible to
scan the entire root file system of a Red Hat server with Aide without
running it for several days?
I've checke dthere are no problems with memory or CPU usage.
Any advice would be appreciated.
We really need to get these times down ideally without taking out or
excluding directories.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130828/29a538f5/attachment-0001.html

[Keith Constable]

Hi my organization is not satisfied with the deafult aide configuration. We want to look at all the files in the root file system without excluding directories for security reasons. We know that certain directories will only be checked for certain attributes for example log files would not have mtime checked. However I have run a few configurations below scanning the whole root to see what attributes we can whittle down to produce a more efficient configuration and its taking an enormous amount of time.
I'm using the below configuration.
CUSTOMTEST1=p+i+u+g+m+acl+selinux+md5
CUSTOMTEST2=p+i+u+g+s+n+m+acl+selinux
These are on rhel 6 servers this is scanning the whole root.
so for example
@@ifhost test77
/ CUSTOMTEST1
@@ifhost test77
[root at aid70 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg0-lvroot
48G 3.1G 42G 7% /
tmpfs 937M 0 937M 0% /dev/shm
/dev/sda1 1007M 67M 890M 7% /boot
The CUSTOMTEST1 config on aide.init continues to run after 3 days.
The CUSTOMTEST2 config has been running for more than 30 hours.
We figured that the removal of a checksum would help performance but both are taking extremely long.
Are we butting heads with something in the file system. Is it impossible to scan the entire root file system of a Red Hat server with Aide without running it for several days?
I've checke dthere are no problems with memory or CPU usage.
Any advice would be appreciated.
We really need to get these times down ideally without taking out or excluding directories.
Thank you.

Mason,

Is this during --init or --check? Though, neither one should take anywhere near that long on such little data.

If I were in your shoes, I would try running aide with the -V231 argument. It turns on just enough verbosity to show you what files it's working on without being overwhelming. You can go up to -V255 if you feel you need more info.

Regards,

Keith Constable



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2849 bytes
Desc: not available
Url : https://mailman.cs.tut.fi/pipermail/aide/attachments/20130828/63915157/attachment.bin

[Mason Nakadomari]

Thank you for the response. I am running aide.init. Yeah we thought it was
strange given its only 50 gigs in root. I'll try that. We feel that it must
be getting stuck somewhere. But even running on different machines doesn't
work.

Post by Mason Nakadomari
Hi my organization is not satisfied with the deafult aide configuration.

We want to look at all the files in the root file system without excluding
directories for security reasons. We know that certain directories will
only be checked for certain attributes for example log files would not have
mtime checked. However I have run a few configurations below scanning the
whole root to see what attributes we can whittle down to produce a more
efficient configuration and its taking an enormous amount of time.

Post by Mason Nakadomari
I'm using the below configuration.
CUSTOMTEST1=p+i+u+g+m+acl+selinux+md5
CUSTOMTEST2=p+i+u+g+s+n+m+acl+selinux
These are on rhel 6 servers this is scanning the whole root.
so for example
@@ifhost test77
/ CUSTOMTEST1
@@ifhost test77
[root at aid70 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg0-lvroot
48G 3.1G 42G 7% /
tmpfs 937M 0 937M 0% /dev/shm
/dev/sda1 1007M 67M 890M 7% /boot
The CUSTOMTEST1 config on aide.init continues to run after 3 days.
The CUSTOMTEST2 config has been running for more than 30 hours.
We figured that the removal of a checksum would help performance but both

are taking extremely long.

Post by Mason Nakadomari
Are we butting heads with something in the file system. Is it impossible

to scan the entire root file system of a Red Hat server with Aide without
running it for several days?

Post by Mason Nakadomari
I've checke dthere are no problems with memory or CPU usage.
Any advice would be appreciated.
We really need to get these times down ideally without taking out or excluding directories.
Thank you.

Mason,

Is this during --init or --check? Though, neither one should take anywhere
near that long on such little data.

If I were in your shoes, I would try running aide with the -V231 argument.
It turns on just enough verbosity to show you what files it's working on
without being overwhelming. You can go up to -V255 if you feel you need
more info.

Regards,

Keith Constable




_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130828/c7a8347b/attachment.html

[Keith Constable]

Thank you for the response. I am running aide.init. Yeah we thought it was strange given its only 50 gigs in root. I'll try that. We feel that it must be getting stuck somewhere. But even running on different machines doesn't work.

Mason,

It just occurred to me that since you did not tell it not to, aide may be attempting to generate a hash for one of the never ending files in /dev like /dev/zero or /dev/random. I'm not certain it will do that, as I've never tried, but it seems likely. I doubt it treats "special" files any differently than regular ones. Dhr. van den Berg could tell you more than I about that.

In addition, prepare for some unbidden advice. Whether you heed it or not is not my concern, but I would be remiss not to try. Your plan to monitor every change in the entire filesystem may not necessarily improve your security. Be careful not to include so many frequently changing files that it generates a report that's too long. You're more likely to miss that one important change if you have to sift through a mountain of unimportant ones.

Regards,

Keith Constable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130828/524f622d/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2849 bytes
Desc: not available
Url : https://mailman.cs.tut.fi/pipermail/aide/attachments/20130828/524f622d/attachment.bin

[Mason Nakadomari]

Thanks the goal is monitor everything but to tailor it to the files and
system. So we fully intended to only monitor things like permissions for
files that change a lot or things like /dev. But we didn't think that
looking at them at all would cause such a hang up. We are even trying to
scan using only a few basic parameters like u+p. That is good advice and we
are trying to tailor it so everything is monitored but that it doesn't pick
up on useless info. That is part of what I am trying to tweak with this.
Thanks very much for the advice. Is it impossible to scan /dev /sys and
/proc even with very basic parameters like u+p+i?

Post by Mason Nakadomari
Thank you for the response. I am running aide.init. Yeah we thought it was
strange given its only 50 gigs in root. I'll try that. We feel that it must
be getting stuck somewhere. But even running on different machines doesn't
work.
Mason,
It just occurred to me that since you did not tell it not to, aide may be
attempting to generate a hash for one of the never ending files in /dev
like /dev/zero or /dev/random. I'm not certain it will do that, as I've
never tried, but it seems likely. I doubt it treats "special" files any
differently than regular ones. Dhr. van den Berg could tell you more than I
about that.
In addition, prepare for some unbidden advice. Whether you heed it or not
is not my concern, but I would be remiss not to try. Your plan to monitor
every change in the entire filesystem may not necessarily improve your
security. Be careful not to include so many frequently changing files that
it generates a report that's too long. You're more likely to miss that one
important change if you have to sift through a mountain of unimportant ones.
Regards,
Keith Constable
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130829/c46908da/attachment.html

[Marc Haber]

Post by Mason Nakadomari
We figured that the removal of a checksum would help performance

No. aide is almost always disk-bound, computing the checksum happens
in negligible time on today's system. You're waiting for your disk,
nothing else.

Run aide with a higher verbosity level and check whether it is hanging
in /dev, /proc or /sys. I'd exclude those directories without much
thinking.

Greetings
Marc

[Mason Nakadomari]

Hi we are using fibre channel and sas disks off a vmware cluster. So I'm
not sure that would be a problem. Any recommendations on what in particular
to exclude from /proc /sys /dev. We don't want to exclude all of those
directories. I will try to see if that is my problem.

Post by Marc Haber

Post by Mason Nakadomari
We figured that the removal of a checksum would help performance

No. aide is almost always disk-bound, computing the checksum happens
in negligible time on today's system. You're waiting for your disk,
nothing else.
Run aide with a higher verbosity level and check whether it is hanging
in /dev, /proc or /sys. I'd exclude those directories without much
thinking.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130829/c6930a51/attachment.html

[Mason Nakadomari]

Meaning I will see if my scans go faster without those directories but I'd
still like to scan those directories in a way to make it faster. It
shouldn't be impossible to scan those directories should it?

Post by Mason Nakadomari
Hi we are using fibre channel and sas disks off a vmware cluster. So I'm
not sure that would be a problem. Any recommendations on what in particular
to exclude from /proc /sys /dev. We don't want to exclude all of those
directories. I will try to see if that is my problem.

Post by Marc Haber

Post by Mason Nakadomari
We figured that the removal of a checksum would help performance

No. aide is almost always disk-bound, computing the checksum happens
in negligible time on today's system. You're waiting for your disk,
nothing else.
Run aide with a higher verbosity level and check whether it is hanging
in /dev, /proc or /sys. I'd exclude those directories without much
thinking.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130829/a91ff07b/attachment.html

[Keith Constable]

Meaning I will see if my scans go faster without those directories but I'd still
like to scan those directories in a way to make it faster. It shouldn't be impossible
to scan those directories should it?

You can certainly scan them. In fact the aide documentation recommends
scanning /dev. If I were to scan directories like those, I would use
aide's built in rule named "L", which does not check properties that
are more or less meaningless for special files (for example, the
checksum of /dev/sda is the checksum of the entire content of the
drive, not the device file itself).

http://aide.sourceforge.net/stable/manual.html#config

Did running aide with the verbose option show if it was getting stuck
on any particular file?

Regards,

Keith Constable

[Marc Haber]

Post by Mason Nakadomari
Meaning I will see if my scans go faster without those directories but I'd
still like to scan those directories in a way to make it faster. It
shouldn't be impossible to scan those directories should it?

/proc and /sys - on Linux - are virtual file systems that the kernel
fills with information about the system and that are used to configure
certains aspects of the system. An attacker is very unlikely to place
data in there.

/dev/ should be scanned with certain exceptions. Any moderately
experienced Unix admin should know which files should be excluded
(disks, random, zero come to mind).

Greetings
Marc

[Mason Nakadomari]

Thanks our group has some experience but we are relatively new to Red Hat
and we have some solaris experience. Its just that we are trying to be very
rigorous to meet security requirements. We have found we need something
tighter than the default settings. Is there a recommended tighter
configuration for Red Hat. I just want to compare to what we are trying to
accomplish. My boss knows that from a theoretical standpoint its useless to
look there but he wants evidence and reasons before excluding. Sorry if
some of this seems foolish, I'm aware that certain one of those files in
/dev or /proc would be problematic to scan. We just wanted to scan as much
as we can with the bare minimum of what is needed to make sure that those
files haven't been compromised. Any advice is appreciated and you've helped
me by leaps and bounds. Thanks.

Post by Marc Haber

Post by Mason Nakadomari
Meaning I will see if my scans go faster without those directories but

I'd

Post by Mason Nakadomari
still like to scan those directories in a way to make it faster. It
shouldn't be impossible to scan those directories should it?

/proc and /sys - on Linux - are virtual file systems that the kernel
fills with information about the system and that are used to configure
certains aspects of the system. An attacker is very unlikely to place
data in there.
/dev/ should be scanned with certain exceptions. Any moderately
experienced Unix admin should know which files should be excluded
(disks, random, zero come to mind).
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130829/a8352e97/attachment-0001.html

[Mason Nakadomari]

I'm enacting some of your advice immediately thank you very much to the
both of you. I'll let you know my progress. I know I'm a rookie at this but
I appreciate the help.

Post by Marc Haber

Post by Mason Nakadomari
Meaning I will see if my scans go faster without those directories but

I'd

Post by Mason Nakadomari
still like to scan those directories in a way to make it faster. It
shouldn't be impossible to scan those directories should it?

/proc and /sys - on Linux - are virtual file systems that the kernel
fills with information about the system and that are used to configure
certains aspects of the system. An attacker is very unlikely to place
data in there.
/dev/ should be scanned with certain exceptions. Any moderately
experienced Unix admin should know which files should be excluded
(disks, random, zero come to mind).
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130829/b4c2c38d/attachment.html

[Mason Nakadomari]

I've removed /proc /dev /sys from my scans and even cutdown on /var/spool
and /var/log. However my scans are still taking more than 24 hours to
complete. Any other recommended configs. The aide manual gave hints but
nothing definite. Still having trouble completing an init. Sorry but I'm
getting frustrated. I suspect I'm doing this wrong somehow. All the checks
are done via a centralized server and it sshs into the desired host. Please
advise. I'm sorry if it seems like I don't know beans. I don't know aide
very well. Thanks.

Post by Mason Nakadomari
I'm enacting some of your advice immediately thank you very much to the
both of you. I'll let you know my progress. I know I'm a rookie at this but
I appreciate the help.

Post by Marc Haber

Post by Mason Nakadomari
Meaning I will see if my scans go faster without those directories but

I'd

Post by Mason Nakadomari
still like to scan those directories in a way to make it faster. It
shouldn't be impossible to scan those directories should it?

/proc and /sys - on Linux - are virtual file systems that the kernel
fills with information about the system and that are used to configure
certains aspects of the system. An attacker is very unlikely to place
data in there.
/dev/ should be scanned with certain exceptions. Any moderately
experienced Unix admin should know which files should be excluded
(disks, random, zero come to mind).
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130901/409a23bb/attachment.html

[Christoph Wilke]

Hi,

On Sun, 1 Sep 2013 23:47:02 -1000

Post by Mason Nakadomari
I've removed /proc /dev /sys from my scans and even cutdown on /var/spool
and /var/log. However my scans are still taking more than 24 hours to
complete. Any other recommended configs. The aide manual gave hints but
nothing definite. Still having trouble completing an init. Sorry but I'm
getting frustrated. I suspect I'm doing this wrong somehow. All the checks
are done via a centralized server and it sshs into the desired host. Please
advise. I'm sorry if it seems like I don't know beans. I don't know aide
very well. Thanks.

please run with -V231 or even -V255 as recommended by Keith Constable earlier
in this thread.
For example:
aide -V231 --init
or similar.

This will help you to find the timeconsuming files.

Best Regards
Christoph Wilke

Post by Mason Nakadomari

Post by Mason Nakadomari
I'm enacting some of your advice immediately thank you very much to the
both of you. I'll let you know my progress. I know I'm a rookie at this but
I appreciate the help.

[...]

[Mason Nakadomari]

Thanks. I am running a verbose scan. I'm gonna check it out. I just
expected faster scans when I omitted certain directories. I'll go ahead and
display the output I encountered.
On Sep 2, 2013 12:24 AM, "Christoph Wilke" <chris at filmkreis.tu-darmstadt.de>

Post by Christoph Wilke
Hi,
On Sun, 1 Sep 2013 23:47:02 -1000

Post by Mason Nakadomari
I've removed /proc /dev /sys from my scans and even cutdown on /var/spool
and /var/log. However my scans are still taking more than 24 hours to
complete. Any other recommended configs. The aide manual gave hints but
nothing definite. Still having trouble completing an init. Sorry but I'm
getting frustrated. I suspect I'm doing this wrong somehow. All the

checks

Post by Mason Nakadomari
are done via a centralized server and it sshs into the desired host.

Please

Post by Mason Nakadomari
advise. I'm sorry if it seems like I don't know beans. I don't know aide
very well. Thanks.

please run with -V231 or even -V255 as recommended by Keith Constable earlier
in this thread.
aide -V231 --init
or similar.
This will help you to find the timeconsuming files.
Best Regards
Christoph Wilke

Post by Mason Nakadomari
On Aug 29, 2013 12:27 PM, "Mason Nakadomari" <nakadoma at hawaii.edu>

Post by Mason Nakadomari
I'm enacting some of your advice immediately thank you very much to the
both of you. I'll let you know my progress. I know I'm a rookie at

this but

Post by Mason Nakadomari

Post by Mason Nakadomari
I appreciate the help.

[...]
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130902/38714b41/attachment-0001.html

[Mason Nakadomari]

Thank you very much I excluded the appropriate directories and I have
gottent he time down considerably and actually completed a scan. Thanks
very much for the help.

Post by Mason Nakadomari
Thanks. I am running a verbose scan. I'm gonna check it out. I just
expected faster scans when I omitted certain directories. I'll go ahead and
display the output I encountered.
On Sep 2, 2013 12:24 AM, "Christoph Wilke" <

Post by Christoph Wilke
Hi,
On Sun, 1 Sep 2013 23:47:02 -1000

Post by Mason Nakadomari
I've removed /proc /dev /sys from my scans and even cutdown on

/var/spool

Post by Mason Nakadomari
and /var/log. However my scans are still taking more than 24 hours to
complete. Any other recommended configs. The aide manual gave hints but
nothing definite. Still having trouble completing an init. Sorry but I'm
getting frustrated. I suspect I'm doing this wrong somehow. All the

checks

Post by Mason Nakadomari
are done via a centralized server and it sshs into the desired host.

Please

Post by Mason Nakadomari
advise. I'm sorry if it seems like I don't know beans. I don't know aide
very well. Thanks.

please run with -V231 or even -V255 as recommended by Keith Constable earlier
in this thread.
aide -V231 --init
or similar.
This will help you to find the timeconsuming files.
Best Regards
Christoph Wilke

Post by Mason Nakadomari
On Aug 29, 2013 12:27 PM, "Mason Nakadomari" <nakadoma at hawaii.edu>

Post by Mason Nakadomari
I'm enacting some of your advice immediately thank you very much to

the

Post by Mason Nakadomari

Post by Mason Nakadomari
both of you. I'll let you know my progress. I know I'm a rookie at

this but

Post by Mason Nakadomari

Post by Mason Nakadomari
I appreciate the help.

[...]
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130904/1f3fdce7/attachment.html

[Mason Nakadomari]

Hi everyone while the time is gotten down its still taking very long about
3 to 4 days to complete. I've been looking at the verbose reports but most
of it just shows the files being digested without really wha tmight be the
problem I can post but I'm not sure how useful it would be. My boss really
wants to scan as much files as possible and I need a reason not to scan
certain directories. I already filtered out the directories suggested just
/sys and /proc. However the scans still take 3 to 4 days to complete and
generate reports 143000 lines long. Is there anyway I can speed this up or
is cutting down on files the only way. Even on single thread should it
really take this long to complete a scan even with a million files it
shouldn't take this long should it? Is there anything I'm missing I should
cut out. I narrorwed out the always changing files of /var/log and
/var/spool only targeting certain files. But I'm not sure what else to cut
out. My boss is paranoid and wants as much of files checked as possible but
question the wisdom of checking in thousands of binaries of firmware files.
I know that a trojan could happen anywhere but I doubt even this would find
it easily. Any tips would be appreciated I'm sorry I just have no idea why
its taking so long. The file system is about 50 GB but at best we are
scanning 20 GB. Thanks any advice is appreciate. I'm sorry for the trouble.

Post by Mason Nakadomari
Thank you very much I excluded the appropriate directories and I have
gottent he time down considerably and actually completed a scan. Thanks
very much for the help.

Post by Mason Nakadomari
Thanks. I am running a verbose scan. I'm gonna check it out. I just
expected faster scans when I omitted certain directories. I'll go ahead and
display the output I encountered.
On Sep 2, 2013 12:24 AM, "Christoph Wilke" <

Post by Christoph Wilke
Hi,
On Sun, 1 Sep 2013 23:47:02 -1000

Post by Mason Nakadomari
I've removed /proc /dev /sys from my scans and even cutdown on

/var/spool

Post by Mason Nakadomari
and /var/log. However my scans are still taking more than 24 hours to
complete. Any other recommended configs. The aide manual gave hints but
nothing definite. Still having trouble completing an init. Sorry but

I'm

Post by Mason Nakadomari
getting frustrated. I suspect I'm doing this wrong somehow. All the

checks

Post by Mason Nakadomari
are done via a centralized server and it sshs into the desired host.

Please

Post by Mason Nakadomari
advise. I'm sorry if it seems like I don't know beans. I don't know

aide

Post by Mason Nakadomari
very well. Thanks.

please run with -V231 or even -V255 as recommended by Keith Constable earlier
in this thread.
aide -V231 --init
or similar.
This will help you to find the timeconsuming files.
Best Regards
Christoph Wilke

Post by Mason Nakadomari
On Aug 29, 2013 12:27 PM, "Mason Nakadomari" <nakadoma at hawaii.edu>

Post by Mason Nakadomari
I'm enacting some of your advice immediately thank you very much to

the

Post by Mason Nakadomari

Post by Mason Nakadomari
both of you. I'll let you know my progress. I know I'm a rookie at

this but

Post by Mason Nakadomari

Post by Mason Nakadomari
I appreciate the help.

[...]
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130907/eac37631/attachment.html

[Richard van den Berg]

However the scans still take 3 to 4 days to complete and generate
reports 143000 lines long. Is there anyway I can speed this up or is
cutting down on files the only way.

Aide is typically IO bound on modern systems. Such long run times
indicate severe disk performance issues. Where is your data store? A NAS
or SAN? You can monitor your IO using vmstat or iotop. Are there other
processes doing a lot of IO on this system?

On my system I scan about 20GB of data in 104388 files and aide always
finishes in a few hours. The data is on a SAN.

Kind regards,

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130908/bcbd96c3/attachment.html

[Mason Nakadomari]

Thank you for the response Richard. I just was beginning to wonder if this
problem was unique to me. Your experience gives me some confidence that
this can be fixed since that is kind of what I have been endeavoring to do.
We use a SAN, Fibre Channel. however we run the aide-server package which
ssh to the host and runs aide on the local server. Both are SAN on fibre
Channel. Ethernet is gigabit. I felt that it shouldn't take that long. I'll
run a iostat but I don't believe I should have io problems. I'll go ahead
and get that info.

I am running it as nohup aide.init hostname & would that make a difference?

However the scans still take 3 to 4 days to complete and generate reports
143000 lines long. Is there anyway I can speed this up or is cutting down
on files the only way.
Aide is typically IO bound on modern systems. Such long run times indicate
severe disk performance issues. Where is your data store? A NAS or SAN? You
can monitor your IO using vmstat or iotop. Are there other processes doing
a lot of IO on this system?
On my system I scan about 20GB of data in 104388 files and aide always
finishes in a few hours. The data is on a SAN.
Kind regards,
Richard
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130908/6397425f/attachment-0001.html

[Mason Nakadomari]

here is what my iostat looks on the local machine. Could it be network
related since I'm running the aide-server package.

[root at aid70 ~]# iostat -dx
Linux 2.6.32-358.el6.x86_64 (aid70.pvt.hawaii.edu) 09/08/13
_x86_64_ (1 CPU)

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz
avgqu-sz await svctm %util
sda 0.00 0.00 0.00 0.00 0.49 0.03
196.52 0.00 4.06 2.38 0.00
sdb 0.01 2.43 0.43 2.78 28.51 41.68
21.88 0.01 1.95 1.32 0.42
dm-0 0.00 0.00 0.44 5.21 28.50 41.67
12.42 0.03 4.75 0.75 0.42
dm-1 0.00 0.00 0.00 0.00 0.00 0.00
8.00 0.00 5.78 0.87 0.00

Post by Mason Nakadomari
Thank you for the response Richard. I just was beginning to wonder if this
problem was unique to me. Your experience gives me some confidence that
this can be fixed since that is kind of what I have been endeavoring to do.
We use a SAN, Fibre Channel. however we run the aide-server package which
ssh to the host and runs aide on the local server. Both are SAN on fibre
Channel. Ethernet is gigabit. I felt that it shouldn't take that long. I'll
run a iostat but I don't believe I should have io problems. I'll go ahead
and get that info.
I am running it as nohup aide.init hostname & would that make a difference?

However the scans still take 3 to 4 days to complete and generate reports
143000 lines long. Is there anyway I can speed this up or is cutting down
on files the only way.
Aide is typically IO bound on modern systems. Such long run times
indicate severe disk performance issues. Where is your data store? A NAS or
SAN? You can monitor your IO using vmstat or iotop. Are there other
processes doing a lot of IO on this system?
On my system I scan about 20GB of data in 104388 files and aide always
finishes in a few hours. The data is on a SAN.
Kind regards,
Richard
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130908/8af709c1/attachment.html

[Mason Nakadomari]

[root at aid70 ~]# iostat -d
Linux 2.6.32-358.el6.x86_64 (aid70.pvt.hawaii.edu) 09/08/13
_x86_64_ (1 CPU)

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.49 0.03 1086378 56968
sdb 3.21 28.50 41.68 62912714 91982864
dm-0 5.65 28.50 41.67 62907794 91978832
dm-1 0.00 0.00 0.00 3568 4032

Post by Mason Nakadomari
here is what my iostat looks on the local machine. Could it be network
related since I'm running the aide-server package.
[root at aid70 ~]# iostat -dx
Linux 2.6.32-358.el6.x86_64 (aid70.pvt.hawaii.edu) 09/08/13
_x86_64_ (1 CPU)
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz
avgqu-sz await svctm %util
sda 0.00 0.00 0.00 0.00 0.49 0.03
196.52 0.00 4.06 2.38 0.00
sdb 0.01 2.43 0.43 2.78 28.51 41.68
21.88 0.01 1.95 1.32 0.42
dm-0 0.00 0.00 0.44 5.21 28.50 41.67
12.42 0.03 4.75 0.75 0.42
dm-1 0.00 0.00 0.00 0.00 0.00 0.00
8.00 0.00 5.78 0.87 0.00

Post by Mason Nakadomari
Thank you for the response Richard. I just was beginning to wonder if
this problem was unique to me. Your experience gives me some confidence
that this can be fixed since that is kind of what I have been endeavoring
to do. We use a SAN, Fibre Channel. however we run the aide-server package
which ssh to the host and runs aide on the local server. Both are SAN on
fibre Channel. Ethernet is gigabit. I felt that it shouldn't take that
long. I'll run a iostat but I don't believe I should have io problems. I'll
go ahead and get that info.
I am running it as nohup aide.init hostname & would that make a difference?
On Sat, Sep 7, 2013 at 11:45 PM, Richard van den Berg <richard at vdberg.org

However the scans still take 3 to 4 days to complete and generate
reports 143000 lines long. Is there anyway I can speed this up or is
cutting down on files the only way.
Aide is typically IO bound on modern systems. Such long run times
indicate severe disk performance issues. Where is your data store? A NAS or
SAN? You can monitor your IO using vmstat or iotop. Are there other
processes doing a lot of IO on this system?
On my system I scan about 20GB of data in 104388 files and aide always
finishes in a few hours. The data is on a SAN.
Kind regards,
Richard
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130908/88185e53/attachment-0001.html

[Richard van den Berg]

Post by Mason Nakadomari
here is what my iostat looks on the local machine. Could it be network
related since I'm running the aide-server package.

IO performance can absolutely be network related when you are using a
SAN. I don't know what the aide-server package is though.

Kind regards,

Richard

[Mason Nakadomari]

Thanks. Basically aide is run from a central server via ssh on the intended
host. I just wanted to clarify that I wasn't running aide straight
standalone on the intended host. I figured that made a difference? I'll
look into io and the network. I don't see anything obvious yet. Thanks for
the help Richard.

Post by Richard van den Berg

Post by Mason Nakadomari
here is what my iostat looks on the local machine. Could it be network
related since I'm running the aide-server package.

IO performance can absolutely be network related when you are using a
SAN. I don't know what the aide-server package is though.
Kind regards,
Richard
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130908/0e5d24b4/attachment.html

[Mason Nakadomari]

Thank you very much Richard. I was able to fix the problem. We use a custom
script to launch it and it does not do well when you try to run the program
in the background. I have resolved it. Thank you for your help.

Post by Mason Nakadomari
Thanks. Basically aide is run from a central server via ssh on the
intended host. I just wanted to clarify that I wasn't running aide straight
standalone on the intended host. I figured that made a difference? I'll
look into io and the network. I don't see anything obvious yet. Thanks for
the help Richard.

Post by Richard van den Berg

Post by Mason Nakadomari
here is what my iostat looks on the local machine. Could it be network
related since I'm running the aide-server package.

IO performance can absolutely be network related when you are using a
SAN. I don't know what the aide-server package is though.
Kind regards,
Richard
_______________________________________________
Aide mailing list
Aide at cs.tut.fi
https://mailman.cs.tut.fi/mailman/listinfo/aide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.cs.tut.fi/pipermail/aide/attachments/20130910/78810109/attachment.html

[Richard van den Berg]

Post by Mason Nakadomari
I am running it as nohup aide.init hostname & would that make a difference?

No, that does not make any difference.

Kind regards,

Richard