Added the possibility to use Alpine as OS

[redvex2460]

Tested in a alpine-docker

[Sebastian-Roth]

@redvex2460 Thanks for your work on adding support for Alpine to FOG. Are you willing to maintain this part of the FOG installer as well? The current developer team is small and busy and we can't afford the time to maintain another distro on top.

The master branch is only used for releases. Please make your pull request towards the code in dev-branch.

[mastacontrola]

@Sebastian-Roth

I've been working on adding this too the working-1.6 branch of course. I'm making a slight difference in the web server stuff in that I'm attempting to add a feature allowing nginx or apache. So I'm generalizing the webserver a bit more than how this PR is attempting.

[Sebastian-Roth]

@redvex2460 I am still wondering if we should make this part of the code. There were discussions on dropping OS support in the forums. Don't get me wrong, I don't fancy throwing away your great work on adding Alpine OS support to FOG. But we do need people to keep up with the OS support and we ask you to help with it as you brought this up here. If we don't hear from you within the next two weeks we'll close this pull request unsolved and remove what was added to working-1.6 already.

[redvex2460]

hey @Sebastian-Roth I don't know what it's used to be a maintainer for features.
I guess I could take care of that code here and there but I'm a private dev, doing that coding beside my main Job.
Tell me what you want me to do, I guess I could try to catch, could also be a nice entry in my portfolio

[Sebastian-Roth]

@redvex2460 said:

I don't know what it's used to be a maintainer for features.

I can't tell you that either. It mostly depends on how many changes in package names and possibly default config changes (just thinking about some service we use in FOG based on default config that could break if Alpine changes things - we had that with vsftpd and isc-dhcp in other distros in the past) Alpine OS does.

I don't know the package naming schema of Aline OS yet. Doing a quick search on the package that is causing the most trouble with other distros - PHP - it seems like Alpine OS only uses one name for PHP7 and PHP8 each. Is that correct? That'd be pretty easy compared to Debian/Ubuntu where we have php7.0, php7.2, php7.4, php8.0.

As well Alpine OS uses subpackages to organize all the different PHP modules (like php-curl). Not sure if that is easy and stable to use or changed a lot?

All in all keeping up with supporting an OS in FOG is just keeping up with the changes. So whenever a new Alpine OS release is on the door step you'd do a FOG install using the latest dev-branch code to see if it's all still working or not. There is no release cycle in FOG that you need to follow.

I guess I could take care of that code here and there but I'm a private dev, doing that coding beside my main Job.

Each and every FOG developer is working on this in her/his private time - beside jobs and family.

Tell me what you want me to do, I guess I could try to catch, could also be a nice entry in my portfolio

Just sticking around and being responsive would be enough for now.

As Tom added your changes to the working-1.6 branch we need to get that into dev-branch as well. That's my part but I am pretty sure I will get back to you with questions on this soon.

[Sebastian-Roth]

@redvex2460 Welcome aboard, great to have you with us. Don't worry, there is no big asks or anything with it.

[Sebastian-Roth]

@redvex2460 I started to look into adding this to dev-branch but failed to do so because there are a fair amount of issues that prevent FOG from installing properly on Alpine with the changes proposed. I will be back onto this when I find some more time in the next weeks.

[redvex2460]

@redvex2460 I started to look into adding this to dev-branch but failed to do so because there are a fair amount of issues that prevent FOG from installing properly on Alpine with the changes proposed. I will be back onto this when I find some more time in the next weeks.

Im on it, cloned dev-branch and will test and rework script.

[Sebastian-Roth]

@redvex2460 I am sorry, I phrased this the wrong way. I was hoping to include your changes into dev-branch but got stuck in working-1.6 already. I think it's best we make it work properly in working-1.6 first and then we can easily apply that to dev-branch later on.

Not sure if you are aware of issue #447 - we plan to remove ARCH support now as there is no one working on this part. So my plan is to reuse the osid 3 for Alpine now. Worked on this a bit more and pushed some changes: 8950b7b

Though there are still some major issues:

1. We have some kind of logic included that tries to work around the problem that database package names have changed over the years - code reference. I think we even tried to help people move from mysql to mariadb that way some years back. But this logic assumes that mariadb is only ever used as a package name for the database client stuff. In Alpine they use the package name mariadb for the database server part I learned. Our funky logic can't handle that. The only solution for now is to manually install this package beforehand and not let it do the installer. I would really like to get rid of that old part of the installer script altogether as it's just very hard to get this right for various distros and versions. Though this means we need to heavily test the scripts after the change to see if it can mess up installs or updates on other distros. So this will be some major work.
2. I think the part for php7-mysqli (code reference) did not work for me. Have not had the time to check way. I simply wonder if we can and should remove that funky logic just as pointed out above.
3. I guess enabling the init scripts (code reference) is not working on Alpine yet.
4. Modifying the database config (code reference) lead to an error on my basic Alpine install just because there are some broken soft links within the /etc directory causing the recursive grep to error out. I think this was needed on Ubuntu years ago because the database was only accessible locally but we need remote DB connections for storage node setups. I have no idea if this is still needed. Wee need to further investigate and do test installs before we can mess with this part of the code.
5. I am wondering if we could stick to Apache webserver for now even on Alpine. It's just adding more complexity to maintain two different webservers (not just package names but also config syntax, config file names etc.). I can see us moving over to nginx altogether at some point but not in a rush.
6. May I ask you why you have all that many php packages included in the list (code reference)?

[redvex2460]

@redvex2460 I am sorry, I phrased this the wrong way. I was hoping to include your changes into dev-branch but got stuck in working-1.6 already. I think it's best we make it work properly in working-1.6 first and then we can easily apply that to dev-branch later on.

Not sure if you are aware of issue #447 - we plan to remove ARCH support now as there is no one working on this part. So my plan is to reuse the osid 3 for Alpine now. Worked on this a bit more and pushed some changes: 8950b7b

Though there are still some major issues:

1. We have some kind of logic included that tries to work around the problem that database package names have changed over the years - [code reference](https://github.com/FOGProject/fogproject/blob/working-1.6/lib/common/functions.sh#L787). I think we even tried to help people move from mysql to mariadb that way some years back. But this logic assumes that `mariadb` is only ever used as a package name for the database **client** stuff. In Alpine they use the package name `mariadb` for the database server part I learned. Our funky logic can't handle that. The only solution for now is to manually install this package beforehand and not let it do the installer. I would really like to get rid of that old part of the installer script altogether as it's just very hard to get this right for various distros and versions. Though this means we need to heavily test the scripts after the change to see if it can mess up installs or updates on other distros. So this will be some major work.

2. I think the part for `php7-mysqli` ([code reference](https://github.com/FOGProject/fogproject/blob/working-1.6/lib/common/functions.sh#L843)) did not work for me. Have not had the time to check way. I simply wonder if we can and should remove that funky logic just as pointed out above.

3. I guess enabling the init scripts ([code reference](https://github.com/FOGProject/fogproject/blob/working-1.6/lib/common/functions.sh#L1106)) is not working on Alpine yet.

4. Modifying the database config ([code reference](https://github.com/FOGProject/fogproject/blob/working-1.6/lib/common/functions.sh#L1170)) lead to an error on my basic Alpine install just because there are some broken soft links within the /etc directory causing the recursive grep to error out. I think this was needed on Ubuntu years ago because the database was only accessible locally but we need remote DB connections for storage node setups. I have no idea if this is still needed. Wee need to further investigate and do test installs before we can mess with this part of the code.

5. I am wondering if we could stick to Apache webserver for now even on Alpine. It's just adding more complexity to maintain two different webservers (not just package names but also config syntax, config file names etc.). I can see us moving over to nginx altogether at some point but not in a rush.

6. May I ask you why you have all that many php packages included in the list ([code reference](https://github.com/FOGProject/fogproject/blob/working-1.6/lib/alpine/config.sh#L17))?

tbh, wouldn´t it be a better aproach to split that installscripts into seperate parts?
Like user is selecting which OS he's using, after that it would load that functions.sh from that corresponding folder.

[Sebastian-Roth]

tbh, wouldn´t it be a better aproach to split that installscripts into seperate parts?
Like user is selecting which OS he's using, after that it would load that functions.sh from that corresponding folder.

Well, I am sure there is a lot that needs improving throughout the whole installer scripts. But who's gonna re-work all that? Those scripts have evolved over roughly ten years with several different people adding and adjusting code. So in fact it's all a bit of a mess if you start looking into the details. But it's currently working and the current dev team can't afford the time to re-work the scripts just now. I am just trying to get Alpine included and not break the installer for all the other distros.

[redvex2460]

I reworked my part at around 30% for now with the approach to override that single parts of the installer like the part where it setup mysql. Am 10.03.2022 19:29 schrieb Sebastian-Roth ***@***.***>: tbh, wouldn´t it be a better aproach to split that installscripts into seperate parts? Like user is selecting which OS he's using, after that it would load that functions.sh from that corresponding folder. Well, I am sure there is a lot that needs improving throughout the whole installer scripts. But who's gonna re-work all that? Those scripts have evolved over roughly ten years with several different people adding and adjusting code. So in fact it's all a bit of a mess if you start looking into the details. But it's currently working and the current dev team can't afford the time to re-work the scripts just now. I am just trying to get Alpine included and not break the installer for all the other distros. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned. Message ID: ***@***.***>

[redvex2460]

something like:

./fogproject/lib/common/functions.sh
doOSSpecificIncludes() {
    echo
    case $osid in
        1)
            echo -e "\n\n  Starting Redhat based Installation\n\n"
            osname="Redhat"
            . ../lib/redhat/config.sh
            ;;
        2)
            echo -e "\n\n  Starting Debian based Installation\n\n"
            osname="Debian"
            . ../lib/ubuntu/config.sh
            ;;
        3)
            echo -e "\n\n  Starting Arch Installation\n\n"
            osname="Arch"
            . ../lib/arch/config.sh
            systemctl="yes"
            ;;
        4)
            echo -e "\n\n  Starting Alpine Installation\n\n"
            osname="Alpine"
            . ../lib/alpine/config.sh
            . ../lib/alpine/functions.sh
            ;;
        *)
            echo -e "  Sorry, answer not recognized\n\n"
            sleep 2
            osid=""
            ;;

../lib/alpine/functions.sh
configureHttpd() {
 /// New Code
}

[Sebastian-Roth]

@redvex2460 While I can see your point I think it's making things just worse. Masking functions will make it even harder to understand how things work together I find. Also it means duplicating a fair amount of code in several files.

[redvex2460]

@redvex2460 While I can see your point I think it's making things just worse. Masking functions will make it even harder to understand how things work together I find. Also it means duplicating a fair amount of code in several files.

tbh I`ve done my complete work like this now, and its working flawlessly.

I normaly coding c# so it should be OOP

functions.sh could be like an interface and other scripts would override that functions.

[redvex2460]

New Alpine-Approach

[Sebastian-Roth]

New Alpine-Approach

Thanks for your effort on this. Unfortunately I can't add this code as is:

• It's branched off master and therefore missing a fair amount of changes that were pushed to working-1.6 already
• ARCH support is not removed, re-using osid 3 for Alpione (Script (web services) not launching with PHP8 in Archlinux( /Manjaro Linux) Install #447)
• It's duplicating a fair amount of the script code that would need to be updated accordingly
• This is not solving the issues I pointed out in: Added the possibility to use Alpine as OS #438 (comment)

[redvex2460]

New Alpine-Approach

Thanks for your effort on this. Unfortunately I can't add this code as is:

• It's branched off master and therefore missing a fair amount of changes that were pushed to working-1.6 already
• ARCH support is not removed, re-using osid 3 for Alpione (Script (web services) not launching with PHP8 in Archlinux( /Manjaro Linux) Install #447)
• It's duplicating a fair amount of the script code that would need to be updated accordingly
• This is not solving the issues I pointed out in: Added the possibility to use Alpine as OS #438 (comment)

I guess you have not tried it because that installscript now works flawless, that duplicate of code should be the right way to rework that installscript, you source already that config.sh
This way it would be easier to fix a single OS.

All problems of your last post are gone with that new version. Except that osid and true I branched from master because you added some alpine logic already to working1. 6

[Joly0]

Tbh, i think splitting up the script into different parts improves readability by alot, with minimal one time work that needs to be put into it. Other than that, i like this pr, would be great, if it could get merged.

[Sebastian-Roth]

@Joly0 Will you assist in changing the installer for all the other distros supported as well as testing it? It's not wise to split the scripts up only for one supported distro but leave the rest as is. It will be just a huge mess and not improve anything.

Before we can think about merging this PR it will need to be made against working-1.6 (not master!) as well as address the issues mentioned above.

[Joly0]

Sry for not answering so long. I would assist in testing. I am using his alpine docker for a long while now and it works great so far so i would definitly help in testing this. But as i am not as skilled in bash scripting as i am with powershell scripting, i probably couldnt help alot in rewriting this, but i could still try and help.

[Joly0]

But another thing i had recently in my powershell world is a similiar case like this. I had a huge script that was hardly readable with different tasks and i did split it up into different scripts to improve maintainance and readability. Was a one time task and alot of work, but it was worth it.

Isnt quite like this case here. I did not have to deal with different operating systems and such things, but imo it helps to split things up if its useful like here. One script should be for one "distro".
If someone adds a new distro they would just add a new script and wouldnt have to deal with the old large script and would have to care alot about anythings thats already there.

We could write simple guidelines on how to write, style and format the scripts and could let them it do it their way.

Thats just my view on this one, but i still have the same opinion as last year, that this is a good idea to do. Alot of work for sure, but i think it will be worth it

[Neustradamus]

2023-12-07: Alpine 3.19.0 released:

• https://alpinelinux.org/