#238 Install guide does not work: No downloadable tarball

Step 1: Visit https://gnusocial.network/

Step 2: Press [Install]

An installation guide is shown, I follow steps, but I can't continue at chapter "Getting it up and running". It says:

"Unpack the tarball you downloaded on your Web server"

What tarball could I download? From where?

Hello Narcis

You could go here:

https://notabug.org/diogo/gnu-social/src/master

and then click on the download icon (on the far right):

https://notabug.org/diogo/gnu-social/archive/master.tar.gz

If you want an other version, select a different branch (on the left).

Good luck!

G

As GNU social is currently in development, some documentation is slightly mismatched and we don't provide a tarball currently. The recommended method is cloning the nightly branch or downloading its contents, with the following link: https://notabug.org/diogo/gnu-social/archive/nightly.tar.gz

Feel free to reopen if you have further issues :)

Guide tells to follow web installation to something like:

https://social.example.net/install.php

But this is the content of public root:

actions CHANGELOG.md classes CODE_OF_CONDUCT.md composer.json composer.lock CONTRIBUTING.md COPYING CREDITS.md db doc-src DOCUMENTATION extlib INSTALL.md lib locale mail-src Makefile modules phpunit.xml plugins public README.md RELEASE_NOTES.md scripts tests TODO.md vendorls

(no install.php script)

Note: I don't know how to change open/closed status of this thread.

What environment are you deploying to? What webserver are you using? Only the public folder is intended to be accessible by the webserver

Apache 2.4.38 on Debian 10 (buster)

I'm not too familiar with configuring Apache, but did you see the sample config?

Hi Narcis,

I'm installing nightly on Debian 11. Is it possible that you have php-pear installed ? Try apt purge php-pear.

For Apache:

cd /etc/apache2/sites-available/ cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/gnusocial.conf

and change this file: /etc/apache2/sites-available/gnusocial.conf to match your domain

     ServerName your.domain.name.here

     ServerAdmin webmaster@localhost
     DocumentRoot /var/www/gnu-social/public
     <Directory /var/www/gnu-social/public>
             AllowOverride All
             Order Deny,Allow
             Allow from all
     </Directory>

The DocumentRoot and Directory lines are important: for some domains, you'll have to inlude "/public", without the quote marks, and no trailing /. The Directory AllowOveride All is also crucial, to allow the .htaccess file

cd /var/www/gnu-social (assuming this is where you placed it):

cp DOCUMENTATION/SYSTEM_ADMINISTRATORS/webserver_conf/htaccess.sample .htaccess

a2enmod rewrite

a2ensite gnu-social

Yes, this server it has php-pear installed.

This is the static structure at service filesystem (same as other websites hosted there):

[RO] /srv/www/testing/site.tree/

[RW] /srv/www/testing/site.tree/private/

[RW] /srv/www/testing/site.tree/public/

[RW] /srv/www/testing/site.tree/system/

[RW] /srv/www/testing/site.tree/system/tmp/

[RW] /srv/www/testing/site.tree/system/log/

Any content I need to be directly available from Internet, go to server's "public" subdirectory. Any content to be out of Internet access, go to server's "private" subdirectory.

Apache's DocumentRoot is /srv/www/testing/site.tree/public

Should I copy GnuSocial's public/* to website public/ ? Is it feasible I copy rest of GnuSocial content to website private/ ?

GnuSocial comes with its own version of php-pear (in extlib). You want to use that version, so try apt purge php-pear. Unless that causes conflicts with other sites or applications.

On my Debian server, I set the permissions for the Apache directory of gnu-social:

chown -R www-data:www-data /var/www/path_here

php-pear was installed at webserver for other CMSs requirements. I think it can be better to let GnuSocial use environment's php-pear module instead of its own.

@NarcisGarcia Using the package manager's pear version is not supported and might not work, as there have had to been some changes to the library we've needed to do. Similarly, putting the main files under private won't work without modifications. Is there a particular reason why you'd need to follow that structure? Place GNU social's files in /srv/www/testing/site.tree/ making sure only the public subfolder is accessible to the internet. There's also a docker-compose definition so you can run social in a container, if that would help

I was trying to avoid the need to dedicate a container to a single CMS.

One aspect I rate is to be able to recommend software that better fits to any hosting scenario. What are the concrete modifications to change private files path? It should be a configuration file with a variable to set relative paths to that.

@narcisgarcia I'm a little bit confused... GNU social has the file structure you mentioned and one of the directories is named public.

The intended configuration, and I think this isn't an issue with shared hosting, is that you have something such as: /srv/www/gnusocial/ with the files in the tar.gz you downloaded. And then set in the webserver configuration (in your case apache2) the root for the domain as being /srv/www/gnusocial/public.

Hopefully this helps...

I need to put public files at: /srv/www/testing/site.tree/public

And I need to move all other stuff to: /srv/www/testing/site.tree/private

Then I should configure public part so it finds the other files in private directory.

But why do you need to put it in a private folder? Permissions, or something?

Yes, and I'm not the only one managing that tree.

What are the modifications needed to change private files paths?

Not fully tested, but I made a branch with those changes: https://notabug.org/diogo/gnu-social/src/narcis Alternatively, more easily and more tested would be simply changing the permissions to all the folders to the same as the private folder

Oh thank you!

Is this branch a candidate to add this movable feature to GNU Social? Should I wait it to be accepted by main project? (I wish to be able to upgrade CMS in the future)

You can use it now, but it's unlikely to be merged to the working branches. You can rebase it on each new commit to nightly. This is still not a recommended use case, I would still recommend changing the permission to the folders