How to contribute

Hi, I have been using FreeBSD on and off since 2008 or so. I absolutely love, love FreeBSD. It works well with the way my brain is wired. I only use the command line.
I am setting up my server again with 12.1-RELEASE. I would like to contribute, but I am not sure where to begin or how to do it.
I understand Docker is broken. With guidance maybe I can help with that?? Also, I would love to port openemr, https://www.open-emr.org/ , an electronic health record. However, I am a doctor, not a programmer, hence I would need guidance.

I am not sure where to register, or how to get started.

Thanks, and keep up the awesome work.
 
Install PHP 7, mariadb, and nginx or apache.



The nginx website has docs on running PHP.
Read through the openemr Linux docs. It won't be exactly the same.

I know nothing of openemr but those dependent packages are required so there's your start.
 
I understand Docker is broken.

Docker is fundamentally broken and probably cannot be fixed on any platform ;)

Luckily FreeBSD has always had an alternative called Jails (https://www.freebsd.org/doc/handbook/jails.html).
Whilst you don't have the popular "Docker Apps web store", what you do have is a secure and correct way of partitioning and isolating programs on FreeBSD.

Since openemr seems to have a lot of dependencies, it might be worth giving Jails a shot so not to spam your FreeBSD install.
 
Reading the comment by unitrunker, I understand that this openemr is what I call a "Web Application Server".

Now, question, gutiersa: Do You want to get this running on Your machine, or do You want to build a port, that then can be included in the distribution and installed by everybody?

A few words on the latter case:
Almost any web application server -no matter what it does- does consist of at least three vital components:
  • the application itself
  • some database backend to store all the content data
  • some web server thru which the access happens.
And so, before even starting with implementation, one has to do a couple of 'Architectural Decisions':
  • there are different webservers around, and people may already have one or the other running
  • there are different databases around, and people may have preferences, and -most important- they may already have a working backup/recovery scheme for their database (or they may not, then they will need to devise one).
  • some people will prefer to throw all three components onto one and the same computer, to just get it running. Other, more security-concerned sites will prefer to put each component on a separate computer (or jail, or container) and have some monitoring or firewalling in between them.
When trying to build a package from such a software, the maybe most ambitioned task is to leave these decisions open to the user, as much as possible.
So, this is some thought-stuff for a beginning. ;)
 
What PMc is calling a 'Web Application Server' is very similar to the FAMP Stack.
This is the same concept with FreeBSD, Apache Web Server, MySQL and PHP components.
There is a great resource on Digital Ocean to get these running.
Many projects on FreeBSD use a similar web frontend approach like Zoneminder and Webmin.

The project you are referencing has good documentation.
Here is the /usr/local/etc/php.ini settings needed:

So the best approach to see if you can get it running is to download all these dependencies:
These are Linux based dependencies so some name adjustment will be necessary.
For instance anything named php7* in the list will need to be php73* or php74* on FreeBSD.
My approach would be to install all the packages in the list and then install the webserver and db server.
Many of the dependencies on the list are based around MySQL and Apache so that would be my focus.
Try and get it running first then worry about making it into a port.

The web server is the front-end so you get that running and see if you can get the landing page to come up.
Looking at the documentation this might be doable. Seeing as it has many components to get right it will take some trying.
 
Thanks for the feedback. Yes, security is my first concern. We must comply with so much regulation, that it is not funny.
I ended up using IOCAGE. to set up the server with jails.
I used Nginx with php74 and did get a landing page.
Next is securing it and finishing the rest.
I am most familiar with Mysql. will give 8.0 a try to see if it works.
I would love to retry apache, but a few years back I had issues with memory leaks and was not able to fix it. That is when I switched to Nginx, which ended up here: https://www.open-emr.org/wiki/index.php/OpenEMR_with_nginx_and_php-fpm
My goal was to port it such that others could install it, and be the maintainer of that port, but I do agree that is much too ambitious a project.

Once it's all secure I will post another message.

Thanks so much.
 
The FreeBSD team is always looking for help with documentation so that's an area you could look into as an entry point.
I am most familiar with Mysql. will give 8.0 a try to see if it works.
Well, yes, it works, and has for at least 16 years when I first used it but I would recommend postgreSQL, instead.

I would love to retry apache, but a few years back I had issues with memory leaks
My company ran apache for years and I don't recall such issues but nginx is a good choice, of course.
 
I would like to contribute, but I am not sure where to begin or how to do it.
There's a whole list of orphaned ports (ports that have no maintainer) that are in dire need of some TLC. Have a look through there and see if there's anything you might like to maintain.

I am not sure where to register, or how to get started.
No registration required, unless you want to submit patches/fixes. If you submit a PR you're going to need to create an account here: https://bugs.freebsd.org/bugzilla/
But that's all the registration that would need to be done.
 
Just to jump ahead a bit the porters handbook will help you package this application when you get it up and running.
So you submit a Problem Report (PR) in the Ports Category with your work.
 
The FreeBSD team is always looking for help with documentation so that's an area you could look into as an entry point.

Well, yes, it works, and has for at least 16 years when I first used it but I would recommend postgreSQL, instead.


My company ran apache for years and I don't recall such issues but nginx is a good choice, of course.
I am sure it was a configuration error on my part.
 
There's a whole list of orphaned ports (ports that have no maintainer) that are in dire need of some TLC. Have a look through there and see if there's anything you might like to maintain.


No registration required, unless you want to submit patches/fixes. If you submit a PR you're going to need to create an account here: https://bugs.freebsd.org/bugzilla/
But that's all the registration that would need to be done.
Where are the orphaned ports?
 
The FreeBSD team is always looking for help with documentation so that's an area you could look into as an entry point.

Well, yes, it works, and has for at least 16 years when I first used it but I would recommend postgreSQL, instead.


My company ran apache for years and I don't recall such issues but nginx is a good choice, of course.
Yes, I am also installing PostgreSQL. But why do you prefer it? thanks
 
Regarding porting particular PHP based web application, after at least scanning through the Porter's Handbook, try to understand some PHP based ports Makefiles, for example from Drupal 8 or any other software depending on PHP you are familiar with. You can find list on freshports in the This port is required by: for Run section.

For other ways how to start contributing see also the Junior Jobs page on our wiki and links there.
 
Where are the orphaned ports?
 
Yes, I am also installing PostgreSQL. But why do you prefer it?
I like the small footprint and they use BSD 2Clause license.
I merely recommended FAMP because your project also uses those very applications.
My opinion is there is no sense swimming upstream until you get to thoroughly know your applications needs.
For web server i think lighttpd aligns with my philosophy. Saying that I use nginx and apache on some boxes.
 
Yes, I am also installing PostgreSQL.

Ah, now I'm getting interested. :)

But why do you prefer it? thanks

Well, it is an excellent database that scales well over an extremly wide range - but You can read that everywhere.
The other great feature is with bugs. Bug-hunting is a fun of it's own, but then, when you have trapped and almost caged the bug, you'll need some help from the developers who really know the intrinsics of their code.
And there the quality of communication can differ grreatly. I have shelves full of caged bugs here, some even with complete fixes - but nobody wants them. :( There is nobody to talk to, or one doesn't get an answer, or they have no idea what it is all about, or they start discussions about the definition of "bug"[1]. They just don't want to fix their code.
Not so with postgres. There one gets an answer on the best possible skill level, gets understood, gets help in identifying the root cause, and if it is a postgres issue, the next release will have the fix (12.2 has one of mine ;) - i.e. I found and trapped the bug, the fix is by Tom Lane). And they have a mailing list that gets read, they don't hide in github or other ivory tower.

[1] we have that definition already, from the uWSGI guys: "Remember, if you cannot use uWSGI in some scenario, it is a uWSGI bug." [https://uwsgi-docs.readthedocs.io/en/latest/FAQ.html]
 
I would like to inject some personal opinion here.
I think the best approach for a FreeBSD port is to follow what the upstream project is using.
We all have our favorite DB servers and web servers.
But when a ports user goes upstream to report a problem or ask a forum question it is best if all OS's are using the same components.
Using the components you like is fine for your own build but for public consumption and ease of upgrading I think the parent projects choices should be respected.

I also wanted to point out that our ports do not do any configuring for the user (unlike Linux).
So the pkg-message will need to display your needed settings. It is called "PORTDOCS=" in the Makefile.
This file is a good example:
/usr/ports/multimedia/zoneminder/files/README.FreeBSD
Notice that the ports Makefile references it.
 
I wanted to provide what is in writing for what to use for WebServer and DB.
From openemr:
First install and configure MySQL(or MariaDB), Apache(or another PHP-capable webserver), and PHP.
So nothing rigid here but look at the dependencies. php7-apache2 in particular.

Now on the FreeBSD side this is said:
Do not depend on Apache unless the web app explicitly needs Apache. Respect that users may wish to run a web application on a web server other than Apache.

So it looks like you could use whatever you want as a porter.
From a user perspective I think upstream choices are wise choice.
 
Ok

textproc/html2text is unmaintained.

That is right up my alley. I am reading the instructions. Say I would like to adopt it, which would be my next step?
Thanks so much for all the replies.

Yes, I am also interested in light servers and small database foot prints.
I like sql-ledger, which uses postgreSQL.
 
I'm posting on the run.

mySQL is owned and licensed by Oracle so there's that. In my case, we found pgsql did things mysql didn't but it's been so long I don't recall the discussion.

One server I'm enjoying at the moment is www/h2o.
 
I would like to inject some personal opinion here.
I think the best approach for a FreeBSD port is to follow what the upstream project is using.
We all have our favorite DB servers and web servers.
But when a ports user goes upstream to report a problem or ask a forum question it is best if all OS's are using the same components.
Using the components you like is fine for your own build but for public consumption and ease of upgrading I think the parent projects choices should be respected.

I agree. This is why I didn't mention postgreSQL, although one can probably call me a "fan". It looked like gutiersa 's piece is mainly focused on using mysql. If you then go and change such a preference, then all the additional support work might just stay with you.
 

Ah. Very nice. :)

Now, as this has become a telltale thread about the so-called 'LAMP-stack', I might share my own experiences as well. ;)
It began with this discussion, and then I decided to, well, just do it.

And, btw, to do away with that 'LAMP-stack'. I don't want my Apache to be spammed with dozens of foreign plugins - there's now php plugins, python plugins, phusion passenger plugins, authentication plugins, evasive actions plugins, fcgi- scgi- wsgi- and whatever-gi else plugins, and sooner or later that must end in problems.

So I followed the idea to run the application as a freestanding and self-maintained process, NOT plugged into the webserver. That way the application becomes completely independent from the webserver. That way any webserver can be used, or even multiple ones at the same time, because the Webserver acts now merely as a reverse-proxy and SSL endpoint.
There may be a performance penalty, but then there is also a big advantage: since the communication between webserver and application is now pure TCP, one can at any time look into that communication with tcpdump and see what is actually happening. Memory issues can also be clearly attributed to the respective offender.

With the python stuff which was originally concerned, this is a supported configuration. Then I found that it also works with php/ZEND applications. It even works with my Ruby-on-Rails applications.

Then, as I was already doing it, I decided to do it quite right, and also implement single-sign-on.
Single-sign-on means, the user logs onto their respective gadget and thereby obtains some credentials. The web browser which they use must then pick up those credentials, and transfer them to the webserver. The webserver passes them thru to the application server. The application server evaluates those credentials and then hands them to the application - which might then do whatever it seems fit.

That way there is no more need for those annoying logon-screens on each and every web application, and there is no need to have a user administration in each of them.

All that is now implemented and appears to work, but, although this is not a bug (but on the way I found and fixed about twenty bugs in various components, which urges the conclusion that nobody has done it that way before), as usual, nobody is interested in it. Well then, at least my machines work the way I like it.
 
The FreeBSD team is always looking for help with documentation so that's an area you could look into as an entry point.
I am interested in contributing with documentation as well.
Is there a particular site which helps one track documentation of an open source project?
How is freebsd documentation tracked?
 
And, btw, to do away with that 'LAMP-stack'. I don't want my Apache to be spammed with dozens of foreign plugins - there's now php plugins, python plugins, phusion passenger plugins, authentication plugins, evasive actions plugins, fcgi- scgi- wsgi- and whatever-gi else plugins, and sooner or later that must end in problems.

Yes, I couldn't agree more.

So I followed the idea to run the application as a freestanding and self-maintained process, NOT plugged into the webserver. That way the application becomes completely independent from the webserver. That way any webserver can be used, or even multiple ones at the same time, because the Webserver acts now merely as a reverse-proxy and SSL endpoint.
There may be a performance penalty, but then there is also a big advantage: since the communication between webserver and application is now pure TCP, one can at any time look into that communication with tcpdump and see what is actually happening. Memory issues can also be clearly attributed to the respective offender.

It's a beautiful thing.

With the python stuff which was originally concerned, this is a supported configuration. Then I found that it also works with php/ZEND applications. It even works with my Ruby-on-Rails applications.

Then, as I was already doing it, I decided to do it quite right, and also implement single-sign-on.
Single-sign-on means, the user logs onto their respective gadget and thereby obtains some credentials. The web browser which they use must then pick up those credentials, and transfer them to the webserver. The webserver passes them thru to the application server. The application server evaluates those credentials and then hands them to the application - which might then do whatever it seems fit.

even more beautiful

That way there is no more need for those annoying logon-screens on each and every web application, and there is no need to have a user administration in each of them.

All that is now implemented and appears to work, but, although this is not a bug (but on the way I found and fixed about twenty bugs in various components, which urges the conclusion that nobody has done it that way before), as usual, nobody is interested in it. Well then, at least my machines work the way I like it.

For me this would be zen. I want this too.
 
Back
Top