Show HN: Linux activity recorder

This isn't about the installer. It's about allowing arbitrary commands to be executed as specified by the API.

Specifically, lib/authentication.js receives a new command, passes it to addActivity in lib/execute_services.js, which schedules it to `exec` periodically (the period is defined by the API response) via ExecuteCommand.executeCommand.

As for the user that the sealion-agent is run as, it's started as root, then setuid'ed to the sealion user in index.js, so any update can undo the setuid and allow full root access.

Basically, by installing sealion-agent, I have given you, all of your current employees and of your future employees (both in CA and India) full access to the server.

No offense, but I don't trust you that much.

Unfortunate. It's a bad habit to get into. Random forum goer pastes something in, you're used to installing via this method, you'll execute it without thought. Boom. No longer your system.

> curl doesn't validate SSL certificates

Curl has an option to explicitly disable cert validation:

-k, --insecure (SSL) This option explicitly allows curl to perform "insecure" SSL connections and transfers. All SSL connections are attempted to be made secure by using the CA certificate bundle installed by default. This makes all connections considered "insecure" fail unless -k, --insecure is used.

Maybe you're thinking of an older version?

(edited for formatting)

>To be honest, how is it any different from downloading a random executable and running it?

It isn't, really. Both are creepy.

This is way better than downloading a random executable and running it. (I assume you mean running it as root.) With this, you can grab the install script and see exactly what it uses root for. It only takes a couple minutes. You could even modify the install script to comply to whatever installation scheme you wanted, and probably even make a version that runs without root privs if you're willing to do a few things manually. This mechanism is WAY better than a binary executable installer.

As for the product, it looks really good to me. No mention of encryption of stored data in the privacy statement, which might be a concern for some.

Also it wouldn't hurt to make checksums available for the installer and downloaded tar, for more paranoid folks like me.

It is a script that you can audit if you don't pipe it straight away into bash (with sudo!).

I don't know Sealion and they can be amazing and all, so don't get this comment wrong.

If they want to support Linux systems properly, instead of using a script like that, I would recommend them to use packages and add support per distribution. Each distribution has different tools to add and manage services, and there are different ways to boot the system services. It's not just adding symlinks anymore because upstart and systemd, etc.

Also I'd love to cleanly upgrade/uninstall/etc their agent, so add a repo and I'll install your agent with more confidence.

How do I know I don't like how they install their agent? Because I didn't pipe the script directly into bash.

Let's look at the established alternatives: packages. Packages are checked for corruption and validity.

This isn't so much different from downloading a random executable and running it. Hell, it's worse than that (since the download doesn't get stored for future audits)! But who said executing random executables from the internet is good in the first place?

How can we be sure that the package that's being installed is the one that you intended to be installed?

How can I be sure that the install will be identical across all of my servers?

How can I pin a version that I've vetted for security holes?

How can I distribute this to servers that don't have arbitrary internet access?

How do I configure selinux/apparmor to work with your tool?

How can I uninstall this cleanly?

Curling into a elevated shell is a terrible way to do installs. Packages are cleaner, more secure, and more capable of being trusted. You're making the assumption that your s3 buckets will never be hacked, that your own webservers can never be hacked, and that experienced sysadmins are going to ignore your tool because of the amateur install method.

If the only requirement is that it be started at boot, there are non-root ways to ensure that. Modern cron implementations have an "at reboot" option (@reboot in vixiecron and cronie). Alternatively, a cronjob that runs every 5 minutes or so and checks if the service is running and starts it if its not is doable.

My already-existing nickname loving user Sean Lion is gonna be proper confused when he sees this running!

It looks great. But I don't run any servers at the moment - I'm just an annoying stickler for the truth in marketing.

Thanks for your response. FWIW I think it just needs a line like "our related Yog line of products are trusted [I'll let you have that one!] by 30,000 companies". Assuming that you can verify 30k different companies are actively using them. It's actually got a double edge too as it also tells people that you have other products in this space that will transform their daily drudge of server maintenance in to a veritable nirvana ;0)>

+1 there's a lot of stuff you can find by correlating between the tools.

Since many of these tools are just /procfs readers and you can make something tighter by hitting their data sources directly, rather than scraping existing command line apps (and the source for these apps is generally quite readable).

I get what you mean re: letting users add their own tools, but I think there's some utility from providing/suggesting things people don't already know.

Eg: a cable gets pulled:

- syslog, which is well known, might show a NIC event.

- ethtool and openlldp will tell you your were connected to row 4 port 26 of MySwitch and now you're not. Which is super useful when you need a NOC person to go investigate.

Same here

Just a wild guess but maybe the installer wants the "real" bash and you have dash set up (I think ubuntu and debian do that nowadays).

That or you're missing an executable or some command returns an error that's poorly handled (since we all know proper error handling is borderline impossible in shell scripts...).

That's why I don't get the point of bash scripts: if you want something truly portable you might as well use /bin/sh and if you're willing to compromise a bit of portability for more advanced features you might as well switch to perl or python (perl is probably as likely to be installed on any un*x machine as bash).

Currently, SeaLion agent is meant for 64-bit machines only. 32-bit agents coming soon.

That's expensive.

That's very expensive

Is there any non-commercial vs. commercial distinction? I.E. do I pay the same price for my EC2 instance running tmux+weechat as my multinational enterprise software employer would pay for a production server?