How to contribute

ucomp

Active Member

Reaction score: 39
Messages: 212

.....works well with the way my brain is wired.....
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.

From today, you will be wiring your brain with software development .
it's quite the same : A doctor implants artificial organs, a FreeBSD-Programmer implants code fragments, it's all about copy&paste 😁 Ha Ha

get your fork of :


and follow their instructions to install from source:

Code:
composer install --no-dev
npm install
npm run build
composer dump-autoload -o



now you begin debugging .. you can fix bugs directly in your master-branch
or make a new branch and call it e.g. 'freebsdport' .

if you find bugs in npm/composer/php or elsewhere ,
you'll write a bug-report :
if you have fixed the bug you'll send a git-diff as an attachment to your report.
developers are normally not here in the forum.
Subscribe to your appropriate freebsd-mailing list to get in touch with devs.

but more interesting for your first steps:
I saw you're the author here :
so you seem to be good connected to openemr-community
you should talk to those openemr/node/php -devs if you have code-specific topics.
you normally do this in the issues-tab of openemr-upstream :


you`ll make a git-PR(pull request)
to openemr-upstream if opememr is interested in developing the freebsd-port with you.

the last step for committing a freebsd-port is to send a review to ours Phabricator
after you`ve made your ports-configuration (Makefile etc.), don't think about it for now..
you'll do that if you're finished with getting openemr running under FreeBSD.
But with a little luck there are only few bugs to fix in openemr and you can begin with your ports-configuration-steps...

by the way , I have nothing to do with openemr and never used it but those are the general steps you normally go for a fbsd-port which has its sources on git.

good luck !

Regards
Klaus

--- edit :--
ah, forgot :
if you want, I'll add your port-request to :
https://wiki.freebsd.org/WantedPorts adding your name under : 'Who is working '
.. or you can add it yourself by contacting :

.. oh, one moment, after I took a closer look to your https://www.open-emr.org/wiki/index.php/OpenEMR_with_nginx_and_php-fpm tells me: you got it running under FreeBSD 12.1, great !
I recommend to take a look at e.g. :
https://reviews.freebsd.org/source/ports/browse/branches/2020Q2/www/
to learn of what a port consists.... then try to write your Makefile etc. and subscribe to ports mailing list if you have questions... finally you subscribe to phab and your port will be reviewed. looking to your expertise with openemr/nginx you won't have much problems writing the fbsd-port... so welcome to the bsd-dev- hell :) ...
normally devs work under FreeBSD 13- current and backport ( called MFC) to lower versions. So if you maintain a port the above said (working with the git-source of openemr/npm etc.)) will probably not change because you will upgrade your port to newer versions and fix bugs, so your git-sources-upstream would/should be the base for your port.... while you can apply patches to your port in the ports-tree...
...
----------
 
OP
gutiersa

gutiersa

Member

Reaction score: 7
Messages: 97

From today, you will be wiring your brain with software development .
it's quite the same : A doctor implants artificial organs, a FreeBSD-Programmer implants code fragments, it's all about copy&paste 😁 Ha Ha

get your fork of :


and follow their instructions to install from source:

Code:
composer install --no-dev
npm install
npm run build
composer dump-autoload -o



now you begin debugging .. you can fix bugs directly in your master-branch
or make a new branch and call it e.g. 'freebsdport' .

if you find bugs in npm/composer/php or elsewhere ,
you'll write a bug-report :
if you have fixed the bug you'll send a git-diff as an attachment to your report.
developers are normally not here in the forum.
Subscribe to your appropriate freebsd-mailing list to get in touch with devs.

but more interesting for your first steps:
I saw you're the author here :
so you seem to be good connected to openemr-community
you should talk to those openemr/node/php -devs if you have code-specific topics.
you normally do this in the issues-tab of openemr-upstream :


you`ll make a git-PR(pull request)
to openemr-upstream if opememr is interested in developing the freebsd-port with you.

the last step for committing a freebsd-port is to send a review to ours Phabricator
after you`ve made your ports-configuration (Makefile etc.), don't think about it for now..
you'll do that if you're finished with getting openemr running under FreeBSD.
But with a little luck there are only few bugs to fix in openemr and you can begin with your ports-configuration-steps...

by the way , I have nothing to do with openemr and never used it but those are the general steps you normally go for a fbsd-port which has its sources on git.

good luck !

Regards
Klaus

--- edit :--
ah, forgot :
if you want, I'll add your port-request to :
https://wiki.freebsd.org/WantedPorts adding your name under : 'Who is working '
.. or you can add it yourself by contacting :

.. oh, one moment, after I took a closer look to your https://www.open-emr.org/wiki/index.php/OpenEMR_with_nginx_and_php-fpm tells me: you got it running under FreeBSD 12.1, great !
I recommend to take a look at e.g. :
https://reviews.freebsd.org/source/ports/browse/branches/2020Q2/www/
to learn of what a port consists.... then try to write your Makefile etc. and subscribe to ports mailing list if you have questions... finally you subscribe to phab and your port will be reviewed. looking to your expertise with openemr/nginx you won't have much problems writing the fbsd-port... so welcome to the bsd-dev- hell :) ...
normally devs work under FreeBSD 13- current and backport ( called MFC) to lower versions. So if you maintain a port the above said (working with the git-source of openemr/npm etc.)) will probably not change because you will upgrade your port to newer versions and fix bugs, so your git-sources-upstream would/should be the base for your port.... while you can apply patches to your port in the ports-tree...
...
----------

Yes, I have a working install in FreeBSD 12.1 with Nginx 1.18 and PHP 7.4.5
I don't understand Git very well at all actually.
 

ucomp

Active Member

Reaction score: 39
Messages: 212

Yes, I have a working install in FreeBSD 12.1 with Nginx 1.18 and PHP 7.4.5
...

I have added your work for opememr to :

I don't understand Git very well at all actually.
no matter, as said:
it's all about copy&paste ;-)
and since you got it running, you are now "forced" to write the port-Makefile..
just kidding .. we are always looking for good things coming to FreeBSD ..
and seeing FreeBSD running on medical-servers is one of that good things.. managed by you.. great !
 

PMc

Aspiring Daemon

Reaction score: 367
Messages: 847

It's a beautiful thing.

Thank You, that feels good. :)

Some details: for my postgres databases I needed the pgadmin management tool (which was changed to a web application in version 4; currently not available as port). I got that working with www/uwsgi as the rig, and added the usual surroundings (startup script in rc.d, etc):

Code:
8001  6084     1   0  52  0   5948     32 piperd IsJ   -    0:00.00 daemon: pgAdmin4[6085] (daemon)
8001  6085  6084   0  20  0  78204    448 kqread SJ    -    2:38.31 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini
8001  6085  6084   0  20  0  78204    448 nanslp SJ    -    1:16.15 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini
8001 10787  6085   0  20  0  83840    444 umtxn  IJ    -    0:00.57 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini
8001 10787  6085   0  22  0  83840    444 kqread IJ    -    0:00.29 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini
8001 10787  6085   0  22  0  83840    444 umtxn  IJ    -    0:04.05 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini

Then I did the same thing with a PHP application www/bareos-webui, and that also works well.

There was a lot of development happening with the uWSGI tool a few years ago (and it is a very welcoming environment for C programmers), but sadly that development has ceased in recent time, so when I tried to do the same with ruby apps, I found that support for ruby26 is faulty and for ruby27 it would probably need major work - so I gave up on that, as there are other, better supported options to run ruby apps (e.g. www/rubygem-puma).

I am now sitting on a pile of drafted ASCII notes documenting the things I had to resolve - but as it seems this forum does not provide a blog space for the users. :( (I would like to publish here, but not so on an arbitrary blogspace on the web where I would be dependent on whoever runs that space.)

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

:) It probably is. But from the economical perspective there is the question of usefulness. Single-sign-on implies that all workplaces are equally secure, while in real life they are not: we have distinguished security concerns for the intranet, or for the perimeter where the webservers run, or for folks connecting via VPN, etc.etc.
So in the real world SSO doesn't pay off unless you have a huge number of workplaces which are equally secure (and where SSO is supported by the OS).
 
OP
gutiersa

gutiersa

Member

Reaction score: 7
Messages: 97

I have added your work for opememr to :


no matter, as said:
it's all about copy&paste ;-)
and since you got it running, you are now "forced" to write the port-Makefile..
just kidding .. we are always looking for good things coming to FreeBSD ..
and seeing FreeBSD running on medical-servers is one of that good things.. managed by you.. great !
Thank you, It will be my pleasure.
 
OP
gutiersa

gutiersa

Member

Reaction score: 7
Messages: 97

Thank You, that feels good. :)

Some details: for my postgres databases I needed the pgadmin management tool (which was changed to a web application in version 4; currently not available as port). I got that working with www/uwsgi as the rig, and added the usual surroundings (startup script in rc.d, etc):

Code:
8001  6084     1   0  52  0   5948     32 piperd IsJ   -    0:00.00 daemon: pgAdmin4[6085] (daemon)
8001  6085  6084   0  20  0  78204    448 kqread SJ    -    2:38.31 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini
8001  6085  6084   0  20  0  78204    448 nanslp SJ    -    1:16.15 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini
8001 10787  6085   0  20  0  83840    444 umtxn  IJ    -    0:00.57 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini
8001 10787  6085   0  22  0  83840    444 kqread IJ    -    0:00.29 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini
8001 10787  6085   0  22  0  83840    444 umtxn  IJ    -    0:04.05 /usr/local/bin/uwsgi-3.7 /ext/etc/uwsgi/pgadmin4.ini

Then I did the same thing with a PHP application www/bareos-webui, and that also works well.

There was a lot of development happening with the uWSGI tool a few years ago (and it is a very welcoming environment for C programmers), but sadly that development has ceased in recent time, so when I tried to do the same with ruby apps, I found that support for ruby26 is faulty and for ruby27 it would probably need major work - so I gave up on that, as there are other, better supported options to run ruby apps (e.g. www/rubygem-puma).

I am now sitting on a pile of drafted ASCII notes documenting the things I had to resolve - but as it seems this forum does not provide a blog space for the users. :( (I would like to publish here, but not so on an arbitrary blogspace on the web where I would be dependent on whoever runs that space.)



:) It probably is. But from the economical perspective there is the question of usefulness. Single-sign-on implies that all workplaces are equally secure, while in real life they are not: we have distinguished security concerns for the intranet, or for the perimeter where the webservers run, or for folks connecting via VPN, etc.etc.
So in the real world SSO doesn't pay off unless you have a huge number of workplaces which are equally secure (and where SSO is supported by the OS).
Believe me, signing on has become so complicated nowadays, that we will circle back to a single sing on system eventually. We are using finger printing, facial recognition and VPNs. Sure, why not
 

k3y5

Member

Reaction score: 19
Messages: 47

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.

I think a lot of people overlook jails. We're currently using a MAC/Jailed env on our production servers. Docker and the rest are just a security breach waiting to happen.
 

k3y5

Member

Reaction score: 19
Messages: 47

There is a FreeBSD article called "How to contribute".

There's a post for everything, sometimes they can be hard to find. I also assume there is more than one way to solve a problem. Asking can help gain tangential insight. The developer handbook is very comprehensive, even covering topics like the freeBSD architectural standards. It is one the things I love about freeBSD.
 
OP
gutiersa

gutiersa

Member

Reaction score: 7
Messages: 97

There's a post for everything, sometimes they can be hard to find. I also assume there is more than one way to solve a problem. Asking can help gain tangential insight. The developer handbook is very comprehensive, even covering topics like the freeBSD architectural standards. It is one the things I love about freeBSD.
I agree. My issue is I am setting up my practice. Once that is done, I will be able to organize the port.
 
Top