IJO: Lightweight Web Host/Server Manager

[prastowoagungwidodo]

Project description

This is the IJO, a lightweight and user-friendly server manager. IJO stands for green, the symbol of being environmentally friendly.

All websites need to be hosted. cPanel is currently the most popular web host manager in the world, but it only works if you're running centos or redhat, which are both based on linux. This makes hosting servers less accessible to the everyday user. To fix this, IJO is available on all major platforms.
The alternatives to cPanel often come with a lot of modules you really don't need. For example, when you're just installing an Apache Web Server to host your server it'll also install a SMTP server, FTP server, DNS server and other modules. IJO gives you a clutter-free and modular option to host your websites.
Another issue with many webhosting solutions is that they're very user-unfriendly because of their complicated UI's. With IJO we're focussing on creating a user-friendly UI for both hosting companies and their customers and self-hosting hobbyists.

How it works

The first installation will only have user manager and modules store (contain lists of available modules to install). Server Administrator just need to go to modules store, find their needed modules and just do one click install to install and configure module and service.

I hope this idea can help many small hosting provider that can't run cPanel on their server or has low budget, help developer to manage their server software in easy way.

Why not use Webmin or other server manager software

Webmin is very relevant, but the interfaces is very complicated by end user. I think cPanel still the best ui/ux for end user.

Sentora is similiar to cPanel, but sentora installed everything on the first installation.

Relevant Technology

Open discussion to get relevant technology.

Who is this for

We need an open source alternative to cPanel that can help many small hosting provider and help developer to manage their server apps. Everyone can join this project.

[Describe who this project is suited for. Experienced developers, novice, or beginners?]

Complexity and required time

Complexity

• [ ] Beginner - This project requires no or little prior knowledge of the technolog(y|ies) specified to contribute to the project
• [x] Intermediate - The user should have some prior knowledge of the technolog(y|ies) to the point where they know how to use it, but not necessarily all the nooks and crannies of the technology
• [ ] Advanced - The project requires the user to have a good understanding of all components of the project to contribute

Required time (ETA)

• [ ] Little work - A couple of days
• [ ] Medium work - A week or two
• [x] Much work - The project will take more than a couple of weeks and serious planning is required

GitHUB Repository: https://github.com/ijo-sm/ijo

[stanier]

As someone who has attempted this before, I would like to shed a little light on what all this project would entail if it were to be realized in a way to become more appropriate than the likes of cPanel:

• As you stated in your post, the target audience here would be small hosting providers, mostly, as well as hobbyists. With that in mind, we have to assume that their hardware budgets are lone, meaning that the binary needed to bootstrap this should be as small as possible while still offering the mentioned features.
• Since we are talking about a small-footprint binary handling a wide variety of admin tasks, many tasks will have to be off-loaded to plugins-- some consumers will want to have the option to backup to S3, some won't, so the extra overhead required to support this functionality should be completely optional.
• cPanel covers most of the consumer's basic needs when it comes to basic server administration and reseller hosting. Creating a project with a smaller footprint won't gain too much traction, as you could honestly just recreate their codebase in golang, realizing at least a 30% overall overhead reduction, amd call it a day. Rather, if you are building a new platform from the ground up, you may as well implement more relevant features that have come to light in the recent years-- NoSQL support, serverless function framework integration, distributed control, cloud hosting integration, container support, etc.
• Each one of these features should be outlined as a base plugin-- not included by default with the binary, but made by the same people and able to installed with one click. This isn't really hard in itself, but it can be overwhelming trying to design a plugin system for your project that is able to support all the various requirements of each basic plugin (plugin-to-plugin calls, stat polling, non-blocking tasks calls)
• Whichever language you choose to do this project in may or may not have very good support for creating this plugin system. When I originally attempted this, I chose nodejs as my poison. There were many good plugin frameworks out there, but I decided I needed one that better suited this project's needs for portability/small footprint.
• Your target audience is a wide variety of developers and server hosts. Not all of them will know the same programming language, so you need to either have an interpreter for a common programming language to run your plugins, support a variety of languages, or create your own scripting language. Each one of these implementations has it's own draw-backs. I originally chose nodejs for plugins using environment containers, learned how bad of an idea that was real quick. Then tried to create an RPC-like API to allow plugins of arbitrary language use the plugin framework-- quickly learned how hard it was to do right.
• Do you want your project to be operating system agnostic or not? Some consumers use Windows, some use Linux. Some even use BSD. Should we force them to use the operating system that best accomplishes our goals or maintain a level of universal compatibility with each?
• How many servers can be controlled by one installation? Many consumers are now looking at using multiple servers-- will they need a separate installation for each, or could one installation span multiple systems?
• Assuming you do decide to support multiple system configurations, how will you control each? What functionality will the agent/client on each system have? Will control be centralized? Would a centralized master have to do significantly more heavy lifting, or could you offload any of it's tasks to slave systems? If it's decentralized or has a weak master, how will you handle communication and task promises? What about a highly available control panel?

This is just a small collection of the problems I ran into when planning out my implementation of this years ago. I obsessed over these details so much that it would prevent me from pushing code as I gradually refactored more and more of the system with each commit, until finally I was at a dead-end where I felt the whole system was broken and needed to be rebuilt from the ground up. I eventually took another shot at it a couple years later using a completely new approach, but had to ditch that project for personal reasons.

I strongly encourage anyone capable of this sort of project to go for it. But be warned: if you want to make it the dream panel everyone has been secretly waiting for, it's going to take a lot of work.

Estimated time for a well-rounded prototype of this would be easily three months.

[prastowoagungwidodo]

@stanier thanks for your feedback. I agree with your comments. It maybe spent a couple of months to built plugin systems that can handle many of process. I actually like using Nodejs for the implementation, but still looking for best programming language to built it.

Thank you so much, your list noted! 😸

[JortvD]

Sounds like a fun project, even though there are already a lot of alternatives. I'd love to help.

[FredrikAugust]

Go for it @JortvD, why don't you and @prastowoagungwidodo hop onto slack (or somewhere else) and discuss this! Sounds like a cool project! :)

[prastowoagungwidodo]

Thanks @FredrikAugust for your suggestion.

[FredrikAugust]

Hey, was thinking about using ours, there's a link in the README :)

[prastowoagungwidodo]

@FredrikAugust of course. How to do that?

[FredrikAugust]

Here's a link directly to the new room: https://join.slack.com/t/osi-initiative/shared_invite/enQtNDE2MDAxNTk5MzUxLTJkZmNlYzgzZWZiMDQzMjJjMjdkNWJlZDM1NGFhZmNiOTU2ZTg3MTdhNGJmOTJmZjBhNjMyMDIxMmViOGJkZDk.

[ammannbe]

Is someone already working on this project or still interested? I also thought about a control panel which is docker based, has a plugin system and a small core. The main goal would be flexebility and usability, so you can extend the core by other docker container (which shall communicate via e.g. redis, so it doesn't matter which programming language is used. But as already mentioned this is going to take a lot of time (for only one person).

[KaKi87]

What about https://github.com/ajenti/ajenti ?

[JortvD]

Well, sadly, the project kinda went dead because of a number of reasons. I would like to pick it up again though. The core concept was at the moment of working on the project that, especially for ease of use, flowcharts would be used to describe the experience for the users of the hosted servers (and maybe the communication between interfaces like databases). This would also make containerization, including Kubernetes etc, really clear for non-pro users. These flowcharts, representing the configuration of software on the machine, can also be saved and then easily deployed on other machines. The core would then only contain concepts like users, machines, tasks and the flowchart. The rest can be implemented via modules/plugins. @ammannbe I'd love to hear what you'd think and maybe with more contributors we can really get something like this off the ground.

[prastowoagungwidodo]

Thank you for your attentions guys. I'm very interested about this project, but dont have much time to develop this project, and because it;s not updated for so looong time, i feel give up. But, If you guys want to contribute for this project, i'll go to the fire and let's make it happen. I'm so exited now XD

[ammannbe]

That sounds really interesting. We should clearly specify a rough concept and try to find more contributors. It should be possible to answer all points in stanier's reply.

Have you guys already done some work, concepts, etc. or do we start from zero?

[JortvD]

I did already start on some parts of the projects 2 years ago, but stopped partially because some them really need to be reworked. It may also be smart to take a fresh look on the concepts I came up with back then. There is also the question of which programming language we will be using. My preference goes out to JS and NodeJS, as it is what I'm good at and there are more possible contributors, since it is well-known. But if you prefer something else, I'd happy to learn. And maybe it is smart to move to another method of communication to not bog up this thread. Slack for example. (I'm sadly not able to make an invite link @prastowoagungwidodo)

[TheOtterlord]

I would be interested in working on the project. I have quite a lot of experience in NodeJS and Electron and can work on this a couple of hours a week. I don't use slack, but if once you start a repository and set out the plan, I'll be happy to fork and contribute where I can.

[JortvD]

I've started working on some concepts over at https://github.com/JortvD/meta. I've also cleared the main repo: https://github.com/ijo-sm/ijo.