SeAT 3 just got tagged as stable after a considerable amount of work went into getting it ported to consume ESI.
This release is primarily a feature parity release with the older version 2 with a few new / noteworthy improvements over all. The package used to talk to EVE’s API (then XML, now ESI) has been almost completely rewritten and is a lot faster now.
Ill be the moron volunteer here… I dont mind. What is this for? Im reading the documentation provided, says I need a linux server… Im just curious, and I dont yet speak the lingo coming this deep into computers and databases. Im learning though. I appreciate the help understanding more about your project. Cheers!
Ok great a moron guide is needed to explain how this is setup for alliance/Corp management as the documentation I have found is not written in plain English… just want somewhere ppl sin up to sorts out discord access etc… no clue how that is done though
I set it up on AWS on a t3 with the DB on RDS, after a rather unsuccessful attempt at setting it up in on MediaTemple VPS…
It has LOTS of bugs, majority being with ESI and search auth. The auth takes a LONG time at first (depending on character’s assets, but it seems that new characters are still an issue. You will need to thoroughly optimize your web server and PHP for this software to even run properly. My best guess is that this is due to ALL the character data being pulled at once on auth and then cached, as opposed to being pulled in chunks when a user clicks on the respective character’s info like assets, mail, PI, etc.
With ESI out of the way, admin tools are sloppy. Sometimes doing anything in the app produces a 500 server error (which can mysteriously not happen on the next page refresh) - and if you are running in prod mode, like you most probably will on your app, you will need to access your logs to get a clue what’s going on. Error reporting is a joke, however, and relies on built-in Laravel monolog driver, which just dumps stuff into a file. The problem with that is the fact that the errors won’t tell you much unless you are actually familiar with Laravel and can trace it down in the actual codebase.
Slack support is a joke, which is to be expected provided only 2 devs are working on it.
Conclusion: this could be a great tool provided bugs are fixed and the software is refactored and optimized. I do like the visual representation of things; it is easy to navigate and find stuff in the UI (if that stuff actually loads). Easy to set up the plugins, although not for a total newbie as it requires SSH / Bash knowledge.
I like the fact that it has plugins that let you connect Discord to your app and automatically tie it to role via a bot, although it is missing a TeamSpeak plugin at the moment. The scheduler plugin is easy to use and can ping you via notifications about any ops you schedule. SRP functionality is great along with fittings and doctrines.
I understand you are trying to get SeAT to run on an Amazon Web Service with a remote database on RDS. A way of usage and installation which was not aimed for, nor supported or covered in any of our documentation. I feel frustrated and irritated because i have the need of appreciation and fairness.
SeAT is an open source software project, which takes no liability whatsoever on how someone is using or installing SeAT. We have various ways of installation and usage documented in our extensive documentation: SeAT Documentation.
I would ask you to review your architectural decisions, compare and contrast to the ways SeAT is proven to work with.
I am not aware of any working AWS setups. You might be better of with your own VPS.
Have a look here for maintained community packages. Teamspeak plugin has been tagged for SeAT 3.0 since 29th of July. Community Packages - SeAT Documentation
I questioned some users of SeAT if they are using AWS and have learned that it is indeed possible. You can run SeAT on AWS both bare metal installed or via docker. The bare metal installation does need a lot of maintenance and is hard to configure unless have a reserved instance.
It was suggested to me that if you decide AWS you should run SeAT dockerized. However the cost are immense compared to a dedicated lowtier virtual private server. (Specs are 1GB RAM, 10 GB or HDD - Requirements - SeAT Documentation) which does geniully run SeAT better.
This is one of the response i got and summerized it pretty well:
@herpaderp So yes you can. I tried it briefly done properly (RDS and EC2 seat tool install) and was never happy with all the messing around. Then went to docker on EC2
I personally suggest everyone to use Dockerized-SeAT, a VPS and at least 2GB RAM if you plan to use plugins. If you plan to use SeAT on a setup that has not been documented you are going to be on your own pretty much.
I’d love to get to grips with this but just can’t get my head around the need for such a convoluted and alienating install process. I feel almost like you have to be a Linux buff just to get it installed. Looking up and getting my head around docker just took up way too much of my time so I just dropped it.
Why would a file drop approach and some config files not suffice?
