Hopefully a new ebuild will be available soon... Thanks!
Created attachment 217776 [details] ebuild for rkhunter-1.3.6
I simply adjusted the old rkhunter ebuild to compile the new version. Minor changes were needed: - ppc patch removed because there is now os.dat file more - WISHLSIT removed from dodoc, file doesn't exists anymore Works fine on my server
Created attachment 218199 [details] rkhunter-1.3.6.ebuild includes concerns from bug 301707
Most recent version in portage tree is from 2008. Update is a trivial action. Update offers enhanced security for Gentoo users. Upstream changelog: "This release offers more ease of use by adding more end-user configuration options and aids detection by adding and improving rootkit and malware checks. The change log lists 29 additions including 9 configuration options and details for 12 rootkits, 29 changes including improvements for 15 rootkit checks and 22 bugfixes. Naming a few: * New IGNORE_PRELINK_DEP_ERR configuration option in case of persistent prelink dependency errors. * New USER_FILEPROP_FILES_DIRS configuration option to add files and directories to the file properties check. * New COPY_LOG_ON_ERROR configuration option to copy the log file if any errors or warnings have occurred. * New WEBCMD configuration option to specify the command used to download data file updates from the Internet. * Rkhunter will look for configuration options in the main configuration file, and then in the local configuration file if it exists. * New SHARED_LIB_WHITELIST configuration option for whitelisting preloaded shared libraries. * New WARN_ON_OS_CHANGE configuration option. If unset then no warnings will be shown. * New UPDT_ON_OS_CHANGE configuration option. If set and the O/S has changed then rkhunter will automatically update properties ('rkhunter –propupd'). * Added support for hash functions SHA224, SHA256, SHA384 and SHA512 using CPAN perl modules Digest-SHA-PurePerl or SHA256. * New UPDATE_LANG configuration option. * New ALLOWPROMISCIF configuration option. * New PKGMGR_NO_VRFY configuration option for fine-grained package manager verification process control. * Rootkit checks added: Adore Rootkit (aka strings.o aka Dextenea) cb, CX, Fu, iLLogiC, ld-linuxv.so.1, 'Spanish', trNkit, Xzibit, ZK. * Updated rootkit / malware checks: Ambient (ark), beX2, BOBkit, Dica-kit, Dreams, Enye LKM, evil strings test, Fleakit, FreeBSD, Phalanx2, SHV4, Universal (URK)."
Bump... any chance of this getting into portage any time soon? I hate having to maintain local ebuilds - it just ain't my thing... :)
Ok, I followed the instructions for adding ebuilds like this to my local overlay (I've done it a few times, just not that many) closely, so am fairly sure I did everything right, but the install attempt fails with the following: ERROR: prepare Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch ( rkhunter.conf.patch ) ERROR: app-forensics/rkhunter-1.3.6 failed: Cannot find $EPATCH_SOURCE! Call stack: ebuild.sh, line 54: Called src_prepare environment, line 2374: Called epatch '/usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch' environment, line 1065: Called die The specific snippet of code: die "Cannot find \$EPATCH_SOURCE!"; myhost : Fri May 14, 07:08:34 : ~ # emerge -pqv =app-forensics/rkhunter-1.3.6 [ebuild U ] app-forensics/rkhunter-1.3.6 [1.3.4-r3] USE="-bash-completion" myhost : Fri May 14, 07:09:49 : ~ # and emerge --info: myhost : Fri May 14, 06:59:40 : ~ # emerge --info =app-forensics/rkhunter-1.3.6 Portage 2.1.8.3 (default/linux/amd64/10.0/server, gcc-4.3.4, glibc-2.10.1-r1, 2.6.32-gentoo-r7 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-2.6.32-gentoo-r7-x86_64-AMD_Opteron-tm-_Processor_244-with-gentoo-1.12.13 Timestamp of tree: Fri, 14 May 2010 10:00:01 +0000 app-shells/bash: 4.0_p37 dev-lang/python: 2.5.4-r4, 2.6.4-r1 dev-python/pycrypto: 2.1.0_beta1 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.7.9-r2, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=opteron -O2" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/whyscream /usr/local/portage/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow acl amd64 apache2 berkdb bzip2 cli cracklib crypt cups curl cxx dovecot-sasl dri fam fortran gd gdbm gpm iconv ipv6 mmx modules mudflap multilib mysql ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection sasl session snmp spl sse sse2 ssl sysfs tcpd truetype unicode vhosts xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="prefork" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa via vmware voodoo" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS myhost : Fri May 14, 07:07:30 : ~ #
(In reply to comment #6) > ERROR: prepare > Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: > > /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch > ( rkhunter.conf.patch ) > ERROR: app-forensics/rkhunter-1.3.6 failed: > Cannot find $EPATCH_SOURCE! Well, it portag is really straight forward here, it looks for the file /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch but fails to find it, have you copied it from your portage tree to your overlay?
(In reply to comment #7) > (In reply to comment #6) >> ERROR: prepare >> Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: >> >> /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch >> ( rkhunter.conf.patch ) >> ERROR: app-forensics/rkhunter-1.3.6 failed: >> Cannot find $EPATCH_SOURCE! > Well, it portag is really straight forward here, it looks for the file > /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch but fails > to find it, have you copied it from your portage tree to your overlay? Of course not... and I fail to see how this could possibly be 'obvious'... I would have thought that if a patch file was supposed to be present, it would need to be one specific for said ebuild, not the one from an older version/ebuild from the main portage tree - or, if the version of the patch file for the old version in the main portage tree would work and/or was required, I would have thought whoever posted the ebuild here would have added a comment to 'be sure to copy the rkhunter.conf.patch file from your portage tree to your local overlay'... Is there any documentation explaining how to manage your local overlay that covers this kind of thing?
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > >> ERROR: prepare > >> Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: > >> > >> /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch > >> ( rkhunter.conf.patch ) > >> ERROR: app-forensics/rkhunter-1.3.6 failed: > >> Cannot find $EPATCH_SOURCE! > > > Well, it portag is really straight forward here, it looks for the file > > /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch but fails > > to find it, have you copied it from your portage tree to your overlay? > > Of course not... and I fail to see how this could possibly be 'obvious'... > So if something complains about a missing file, then it is not obvious that there is a file missing? And if there is a version of an ebuild that does not complain about missing file, it is not obvious that it may be because the file exists somewhere where that other ebuild looks for it? > I would have thought that if a patch file was supposed to be present, it would > need to be one specific for said ebuild, not the one from an older > version/ebuild from the main portage tree - or, if the version of the patch > file for the old version in the main portage tree would work and/or was > required, I would have thought whoever posted the ebuild here would have added > a comment to 'be sure to copy the rkhunter.conf.patch file from your portage > tree to your local overlay'... Well, I cannot see a version specified in that file name. The normal convention is that if a file does not vary between releases (like for example this patch to customize rkhunter.conf for things gentoo do differently, or gentoo specific init-scripts) then to not weight down the portage tree with five different named versions of the same file. > > Is there any documentation explaining how to manage your local overlay that > covers this kind of thing? > It is the same documentation that exists for the portage tree. An overlay is nothing more then a local portage tree that if both tree has the same ebuild, your overlay has priority.
(In reply to comment #9) > (In reply to comment #8) >> (In reply to comment #7) >>> (In reply to comment #6) >>>> ERROR: prepare >>>> Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: >>>> >>>> /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch >>>> ( rkhunter.conf.patch ) >>>> ERROR: app-forensics/rkhunter-1.3.6 failed: >>>> Cannot find $EPATCH_SOURCE! >> >>> Well, it portag is really straight forward here, it looks for the file >>> /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch but >>> fails to find it, have you copied it from your portage tree to your >>> overlay? >> Of course not... and I fail to see how this could possibly be 'obvious'... > So if something complains about a missing file, then it is not obvious that > there is a file missing? I didn't say that did I? I said it wasn't obvious that I was supposed to copy a the file from the main portage tree, especially seeing as it was from an older version. >> I would have thought that if a patch file was supposed to be present, it >> would need to be one specific for said ebuild, not the one from an older >> version/ebuild from the main portage tree - or, if the version of the patch >> file for the old version in the main portage tree would work and/or was >> required, I would have thought whoever posted the ebuild here would have >> added a comment to 'be sure to copy the rkhunter.conf.patch file from your >> portage tree to your local overlay'... > Well, I cannot see a version specified in that file name. ??? I'm talking about the fact that I'm upgrading from rkhunter 1.3.4 to 1.3.6. In my mind, it stands to reason that 1.3.6 might require something different from what the patch file for 1.3.4 provides, and the fact is, I don't how to determine if it does or not on my own with even a semblance of certainty. > The normal convention is that if a file does not vary between releases (like > for example this patch to customize rkhunter.conf for things gentoo do > differently, or gentoo specific init-scripts) then to not weight down the > portage tree with five different named versions of the same file. I asked where this is documented... is it too much trouble to say where I can find it? Again - where is this documented? >> Is there any documentation explaining how to manage your local overlay that >> covers this kind of thing? > It is the same documentation that exists for the portage tree. Where??? > An overlay is nothing more then a local portage tree that if both tree has the > same ebuild, your overlay has priority. I understand that much. Where is it documented that I should copy these files from the main portage tree to my local overlay when manually adding custom ebuilds? Do I do this every time? Only certain situations? I'm honestly asking. I don't mind reading, but I have never seen such documentation. If I'm missing it, please tell me where it is and I'll stfu.
(In reply to comment #10) > > Well, I cannot see a version specified in that file name. > > ??? I'm talking about the fact that I'm upgrading from rkhunter 1.3.4 to 1.3.6. > > In my mind, it stands to reason that 1.3.6 might require something different > from what the patch file for 1.3.4 provides, and the fact is, I don't how to > determine if it does or not on my own with even a semblance of certainty. > And in my mind it stands to reason that if the one that created the ebuild thought you had to have a new patch he would had said so and attached that patch to this bug, that is the common way it is handled > > The normal convention is that if a file does not vary between releases (like > > for example this patch to customize rkhunter.conf for things gentoo do > > differently, or gentoo specific init-scripts) then to not weight down the > > portage tree with five different named versions of the same file. > > I asked where this is documented... is it too much trouble to say where I can > find it? Again - where is this documented? > http://devmanual.gentoo.org/ebuild-writing/misc-files/patches/index.html It does not exactly say that you should do it this way, but it says: "If a package requires many patches, even if they are individually small, it is often best to create a patch tarball to avoid cluttering up the tree too much. " Which essentially means: the portage tree should contain as few and as small files as possible, everything else belongs as a distfile on a mirror. > >> Is there any documentation explaining how to manage your local overlay that > >> covers this kind of thing? > > > It is the same documentation that exists for the portage tree. > > Where??? > http://devmanual.gentoo.org/general-concepts/overlay/index.html > > An overlay is nothing more then a local portage tree that if both tree has the > > same ebuild, your overlay has priority. > > I understand that much. Where is it documented that I should copy these files > from the main portage tree to my local overlay when manually adding custom > ebuilds? Do I do this every time? Only certain situations? > The only things needed for an ebuild to work is that it is placed in a <category>/<packagename> directory. It should contain <something>-<version>.ebuild and a Manifest. If the ebuild needs has references to ${FILESDIR} it means that it expect that file to exist in <category>/<packagename>/files > I'm honestly asking. I don't mind reading, but I have never seen such > documentation. If I'm missing it, please tell me where it is and I'll stfu. > Most of the information you can find in the Gentoo Development Manual (which I linked) and in the handbook, http://www.gentoo.org/doc/en/handbook/ Also there is very much in Gentoo that is not well documented anywhere (and they usually are happy with every contribution they get), but when it comes to the official portage tree an idea that usually works for what is placed there is (or should be) "working and slim". And if you cannot find the information in the dev manual or in http://www.gentoo.org/doc/en then irc is really recommendable.
(In reply to comment #7) > (In reply to comment #6) >> ERROR: prepare >> Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: >> >> /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch >> ( rkhunter.conf.patch ) >> ERROR: app-forensics/rkhunter-1.3.6 failed: >> Cannot find $EPATCH_SOURCE! > Well, it portag is really straight forward here, it looks for the file > /usr/local/portage/app-forensics/rkhunter/files/rkhunter.conf.patch but fails > to find it, have you copied it from your portage tree to your overlay? Ok, finally got back to this... I copied the missing file (and the rkhunter.cron), and got 1.3.6 installed, so thanks for the help (and the pointers to the other docs)! :) Now, apparently some things have changed which is causing a lot of 'suspicious files' warnings (59 to be exact) about files in /usr/bin and /usr/sbin having the immutable-bit set... It also had 2 false positives for the Xzibit rootkit (in /etc/init.d/hdparm and /etc/init.d/pciparm), but I found this thread that explained how to whitelist them: http://forums.gentoo.org/viewtopic-t-812558-start-0.html So, now, what is the best way to eliminate these suspicious files warnings? I know I could just whitelist them all, but is that really the best/only way? Doesn't doing so leave you less secure? What if something took advantage of the fact that all of these files are whitelisted? Of course, if it is the only way, then so be it, but thought I'd ask first... Thanks again for helping me get this installed!
More info... I've been using 1.3.4 running nightly for many months, with no warnings. Since upgrading to 1.3.6 - using the same config file as I was with 1.3.4 - I've been getting these warnings on 59 files (in /usr/bin and /usr/sbin): myhost : Sat May 15, 11:35:08 : /var/log # less rkhunter.log | grep Warning [11:30:28] /usr/bin/chattr [ Warning ] [11:30:28] Warning: File '/usr/bin/chattr' has the immutable-bit set. [11:30:28] /usr/bin/curl [ Warning ] [11:30:28] Warning: File '/usr/bin/curl' has the immutable-bit set. After discussing these on the rkhunter list, I now know this is because of the 'immutable' test for files with the immutable flag set. According to the rkhunter dev, this test is not new to 1.3.6, it would also have been running in 1.3.4. So, either the test was not running in 1.3.4 for some reason, even though I had *not* disabled it, or something changed between 1.3.4 and 1.3.6 that is causing the test to warn on these files where 1.3.4 did not. I'm not sure if this is a bug in rkhunter, the gentoo ebuild, or what. I asked on the gentoo forums but haven't had a response yet: http://forums.gentoo.org/viewtopic-t-828420.html So - any ideas? The rkhunter dev asked for the debug output of both programs, but I don't know how to install both versions at the same time...
*** Bug 322189 has been marked as a duplicate of this bug. ***
It's in the tree.
