Not similar at all, but I do use this for viewing / checking combined logs from systems:
Epylog - https://fedorahosted.org/epylog/
It lets you boil down combined syslogs from multiple systems, and get rolled up reports on logins, and a free-for-all report of anything that was not parsed in an email.
It takes quite a bit of time to get what they call the "weeder" to build up to rid yourself of the background noise from the reports, and it does take ocasional changes to regexes on lines to account for some daemons changed log output for warnings, etc, but I find it worthwhile. Once you have your "don't care" lines out of the report, you will be left with the ones to either investigate and act on or just add to the don't care if they turn out to be a more of just miss-placed info output.
You can set up your own roll up reports, but I have not played with that as of yet.
Not the splunk way - there are no "don't care" records, you throw everything in the big index and figure out how to query it later.
Been talking to some former coworkers (now at NYTimes, ghod help them) and one of the Splunk alternatives they are looking at is Sumologic:
https://support.sumologic.com/entries/21863767-How-do-I-group-messages-based-on-a-field-I-define
(^^ one of my litmus tests for a Splunk replacement)
http://www.forbes.com/sites/petercohan/2015/02/25/will-sumo-logic-pin-splunk/
Hrm.
https://www.sumologic.com
When you go to this site, you may be treated to the following popup:
This page ws unable to display a Google Maps element. The provided Google API key is invalid or this site is not authorized to use it. Error Code:
InvalidKeyOrUnauthorizedURLMapError
So, they hope to supplant Splunk, but...?
Hrm... I don't expect you're looking for something like:
ls /etc/init.d
(by way of enumerating services)
This said, apparently, Red Hat prefers 'systemctl' commands.
To list services:
systemctl list-unit-files --type service
unless you're talking about an old Red Hat. Older Red Hat apparently did:
chkconfig --list
(src:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/ System_Administrators_Guide/sect-Managing_Services_with_systemd-Services.html
)
netstat -an | grep LISTEN. Find out what process owns those ports, whether they are truly necessary for your use case, and if not, shut them down.
next, think about local security. Can you enable selinux in strict mode without breaking anything critical?
Red Hat used to have a simple "enable the firewall" script that would install some basic packet filters. I don't remember the name of it anymore, might have been system-config-firewall
Use the "find" command to hunt down setuid/setgid binaries that might not be necessary.
This is basic stuff. I'm not a security guru anymore, if I ever was. Google "Red Hat hardening" or something.
List listening sockets and proggies):
netstat -aonp
List the users of the port, and userid:
lsof -ni :portnumber
i.e.:
lsof -ni :25
Show the individual process info:
cat /proc/[pid]/cmdline
i.e.:
cat /proc/11104/cmdline
(and many other items under /proc/[pid] that interest you (cat is your friend).
Feel free to share anything you learn as well.
the citadel faq has the most important ones:
http://citadel.org/doku.php?id=faq:start#troubleshootingyourhostos
So I finally booted up the Pi that I got for Christmas. But I only had a 2 GB SDcard so I moved my root filesystem to a 250 GB external USB drive.
It was really easy. Everything behaved as I expected it to. All I had to do was rsync to the new filesystem, identify its UUID, call for its mount as rootfs in its own /etc/fstab and in the Pi's boot partition, and reboot.
I like it this way better. The SDcard is /boot and nothing else.
(And yes, it was sooooo satisfying to be able to type "apt-get install citadel-client" on the Pi and get a precompiled Citadel client fed back to me, even though none of us on the project have ever explicitly built on this platform before!)
Fri May 08 2015 11:56:56 EDT from IGnatius T Foobar @ Uncensored
(And yes, it was sooooo satisfying to be able to type "apt-get install citadel-client" on the Pi and get a precompiled Citadel client fed back to me, even though none of us on the project have ever explicitly built on this platform before!)
And that without java - compile once debug everywhere ;-)
That's not really a fair comparison. Sure, the Debian repository is available on every platform, but it's native, so it's compile everywhere debug everywhere.
Java's bad reputation has everything to do with the smear campaign orchestrated against it in the 1990's. Since then it has become the lingua franca of business logic anyway.
Not really. The phrase "compile once, debug everywhere" had a lot of truth to it, borne out by bad experiences with AWT, which turned out to be not be such a panacea for cross-platform portability as was first hoped. It's *hard* to build a cross-platform window toolkit in a way that respects the native look-and-feel of all platforms.
"Compile once, debug everywhere" is *absolutely not true in the same sense* when applied to server-side java, which has proven highly portable.
It was released at a time when there was such a thing as
" native look and feel "
As we all know ... there is no longer any such thing. Web based applications broke everyone's addiction to needing the exact same widget set on every application.
Nowadays, developers use whatever chrome they want. As a result, an application written in Java that uses SWT, say on Windows for example, looks no more "foreign" than Microsoft Office.
The result ... even on the desktop, Java applications now look the same everywhere, because they use the same widget set (and therefore the same pixel-by-pixel dimensions of every widget) on every platform. I like it.
I liked the fact that the Blackdown Java on Linux allowed me to have a Linux workstation and do Java development for Windows back in the late 90's. It was fun having Linux servers push out Jar files to remote web servers via JWS, allowing branch locations running Windows clients to update software in the middle of the work day.
For all the faults people find with Java / Java Web Start and all that, I was able to make some use of it and do some pretty cool testing / release cycles that I have been hard pressed to duplicate (outside of the LAMP stack world).