I vote for a manual that descrips a best practise Seafile Server manual.
Basically it gives the steps required to set a server up and links to existing articles.
It also could give some comments.
Is someone willing to help me with this?
There are so many problems with “Seafile not working” because people do not use a reverse proxy and seem confused by ports and what has to be open/closed.
What do you think?
yes - realy fine idea
and if one would do an installer (like the nice scripts from mr. Jackson) it helps even more 
Someone has to take care of such script.
What I don’t like is that support for Debian and other distros was taken out by the Seafile team. Alexander Jackson put a lot effort into the script to have it work with all distros.
For stability reason we don’t want to user Ubuntu as a server system and want to stick with Debian. At least Debian could be supported. Same goes for distros like RedHat and Suse.
I think we better should have a step by step tutorial for setting up a seafile server with MySQL/MariaDB and memcached behind a reverse proxy, optional with dyndns and a domain validated certificate. Each step should have tests at the end to assure, everything is working up to that point. Then we need hints for troubleshooting in case of something does not work as expected.
Of course scripts will be helpful, but i wouldn’t use a complete installation script, which is doing the whole thing in one go. If something goes wrong, that wouldn’t be very helpful.
I think of setting up a complete server at non-root domain using IPv4 NAT (IPv4 only, dual stack) or Carrier-grade NAT (DS-Lite) or IPv6 only.
My first idea is having some steps like these:
Prerequisites: Set Fix IP address for the server, disable firewall and selinux (if enabled by default)
Create a user to run the seafile server
Install and configure seafile server: Install required packages, mysql (or mariadb) memcached, seafile server, configure the stuff
Backup the installation and data to be able to go back to a working system in case of messing things up in next steps
Create start / stop scripts
Setup webserver as reverse proxy (HTTP accessible from LAN)
Enable firewall
Enable HTTPS using a self signed certificate
Enable access to seafile server from internet (IPv4 / IPv6 if behind carrier grade nat)
Add rewrite rules for HTTP to HTTPS, / to /seafile
Get a domain name (DDNS), setup DynDNS
Get and install a domain validated certificate (Let’s Encrypt?)
Setup a daily backup for seafile data
Optional: Enable selinux if disabled in step 1.
Each step contains the necessary changes in the configuration steps before, i.e. seahub_settings.py will be changed several times in this scenario, but the advantage is having fix points for testing. Backing up the whole thing after each step should be a good fall back strategy.
Personally I prefer CentOS as operating system, but I think Debian would also be fine and it covers Raspberry Pi installations more or less. It could be the better choice. Ubuntu is also not my favorite.
Nginx is my preferred webserver. I used apache some years ago, but I’m not familiar with it any more.
I for one would love a manual for the Windows Server, now I’m stuck on it but I can’t find anything in the manual about the issue =/
Sadly it feels like that I need to go over to run a *nix in a VM for this because of the lack of information and thats noting that are good as my server are running windows server as main OS on it.
I think the biggest problem with the existing server manual is the required information being spread over several chapters. Several options are affecting other parts and there is no guidance to walk through. I think, the manual itself is rather good, everything needed is written somewhere. But is is no tutorial, guidance or how-to and there are almost no checks included, which all are no missions of a manual.
While setting up my first seafile server, I missed something like that sadly. Now after having setup a few seafile servers, I’m willing to write something to help people setup their own seafile server.
I agree with you having a guidance for setting up seafile on a Windows Server would be nice.
Personally I use linux for more then 20 years and dropped Windows in 2000. So I’m surely not the right one to write a tutorial for Windows operating systems. But I think having something for one linux distribution can be easily converted to another linux distribution and even to Windows with a reasonable effort.
Well that’s true, but in my case it’s something with the server as it can accept SSL from every client beside the Windows Client, and the Windows client can connect to the server without SSL.
So it’s safe to say that the issue are in the server or the Windows client but I can’t tell which.
That’s something that shoud bee in the manual how to config the server, not a how to but how to config something.
If you want something decend and stable with a bigger user base you should go for Linux as Server System. I do not say this because I hate Windows (I am forced to use it at home and at work), it’s rather a question of how to get things done and how fast to get problems solved.
You got by now that there are way more Linux admins for server apps around than Windows admins, especially in the OpenSource world. Someone may correct me, but this is what I experienced within the last years.
Exactly that is what i mean. In my proposal (step 8 and step 12) there should be an explanation what the configuration does, some useful options if appropriate and tests like:
nmap server.example.com
curl -I https://server.example.com/seafile/
openssl s_client -connect server.example.com:443
Each test should include an expected output and some hints what can be done if it fails. Some explanations for interpretation of the logfiles will improve it further.
My goal is to enable people to solve their problems by themselves. It is so sad to see people giving up just because they don’t know how to fix their specific problem.
Yes and for now I’m almoste one of them as I don’t get Seafile to work with SSL over Windows Server and the people that have the knowligde about it are so small so it’s not so fun.
We should put this into an extra section for the Seafile Server manual. I can create the folder+files but you should then join these files in Github so we work on them together.
I suggest the following folder structure:
– Best practise server setup
Should contain a summary and an explaination about the purpose of this guide + examples.
— Linux CE
We know what goes here. Of course only with nginx nothing else. Best practise!
----- Pro
Maybe it is enough to put extended points, not everything over again.
— Windows CE
We know what goes here. Of course only with nginx nothing else. Best practise!
What do you think?
Sounds good.
Have a look here, you are welcome to start writing your input.
https://github.com/DerDanilo/seafile-docs/tree/patch-1/best_practise
Before we request a full of these documents we should fill and link them with existing documents or at least link to the pages that contain information that we are using in this guide.
That’s OK for me, but I’ve never used Github. I don’t have a clue how to use it. I need some help to get started.
We can take your structure to get our project started. But we should keep in mind that we need to handle some components in various cases. I think of SysVinit / systemd or firewall: nftables / iptables and so on.
@daniel.pan
I would like to build the best practise guide appart from the server manual with grav.org.
The following theme is very good for “learning” how to setup Seafile: http://demo.hibbittsdesign.org/grav-learn2-git-sync/basics/overview
Grav has a Plugin which automatically pulls files from Github for page content. So there is basically nearby zero managment to be done.
Grav helps to get into setting up Seafile way more easy.
It will containt a straigt forward guide how to setup seafile with:
Later we can then extend the manual with something regarding the pro version.
@daniel.pan
Can you guys please spin up a AWS machine to gost the grav page?
URL for this could be docs.seafile.com, so we can keep the old manual alive until the new one is ready.
Hi, there! I find your idea and effort great!!
Thanks!
Let me just add my two cents:
First thing:
I totally agree! This and sometimes the lack of actualization or late actualization (changed dependencies, …) are the main problems of the actual manual.
Second thing: Some thoughts for a manual.
Do a section which explains the different parts of the seafile server and their function in a more practical way. What do these server parts mean for ports, reverse proxy, usage, etc.
List the dependencies and supported platforms and their changes in a clearer way. (Here the main push should come from the developers! I have the impression, that infos about these things come really late and sometimes only after somebody has asked or has had a problem, because of not knowing.)
It is, of course, not possible to write a manual which covers all use cases, so choose one/two/maybe three important practical use cases/setups for the whole document, which are reasonable transferable to special use cases.
Keep things modular! Here, I have e.g. the web server(s) in mind. Many people ask questions, like does Seafile support "Let’s Encrypt!!! People should understand, what the web server does and what seafile does.
Modularity brings me to the next thing. Try to create a manual in a way, which makes maintenance/actualization simple and easy. (Very difficult though!)
So the idea …
… is very, very good. It would be nice to have a better understandable/organized/not so cluttered way to install Seafile on your system. But please keep in mind that seafile is a quite complex application and you have to know quite some things about servers/“the web”/security/…!!! I often have the impression here in the forum, that people think it is a simple web application, all written in php and everything you have to do is bombing the files in the web root and everything is done.
To make my point clearer: I do support a more practical help for installation and maintenance of seafile: It is ok to handle e.g. a systemd startup script to people, help with vhost configuration, etc., but never forget, that people should also understand the most of what they are typing in the console or copying in a script. So, it would be nice, if there is explanation for the most important things. Of course, not all can be explained, but that is the reason why potential user should bring experience and the willingness to learn a little bit about the things that “carry” seafile and seafile uses itself.
And that brings me to my last point and the most controversial point: The installation script!
@Wolle definitely points it in the right direction! If something with the installation script goes wrong, that wouldn’t be indeed very helpful. That’s the first point! You may need a thousands of installation scripts for the thousand use cases. If you don’t hit the use case for 100 %, it is presumable that something will go wrong. But it would be the least bad thing that could happen. I would go further: People who have installed seafile with these kind of scripts, have no idea what is going up later. (Exception: People who install many many seafile instances, but these kinda guys (should) make their own scripts.) Maybe they have luck with the installation, because their setup meets the requirements and the “one button” installation works, but you will meet a lot of them later in forum. They can’t update their server, have no idea of web server, firewall, system user and permissions, and so on. And that is wrong in so many ways. First let me make it clear, that I AM NOT A PRO, not even close to it. I do not know much about seafile’s technical details and I’m not a king in servers and I think it is great to be able to ask the most noobish question in a community forum without hate. Let’s say, I’m just an interested person. But there is something wrong in the process of distributing software, when there are always the same simple “problems” answered/helped/solved in the forum! That costs time, man power and progression and is obviously completely unnecessary at all. So in my opinion, a good manual (clearly rather than an installation script) can solve a lot of these issues, reduce frustration, invite new users and brings joy to work with.
So I very much appreciate your idea of improving/creating a (practical) manual!
Greets Nytrm
EDIT: Just some typo and grammar.
Thanks! 
Finally someone expressed in details what is going on inside my head for years 
.
@daniel.pan
Because of this we need a manual where we can point out certain points better than right now. We need colors, boxes, frames etc. getgrav.org does just that and has nearby zero maintaining time. It is beeing used in many project worldwide already and I so absolutely no reason not to use it for a Seafile setup guide too.
We totally can keep Gitbook for all Changelogs and special configuration examples. But most of the manual should be transfered to GRAV.
@Seafile Team:
If you prepair hosting GRAV (I recommend some good quality SSD based vHost in Germany, but either is fine) I will host it myself for development of the manual and then push it into your repo once completed, which is way faster than always to wait for your approval for small changes.
This way I can then invite many other users from the forum who want to help build this manual.
Thanks!
If something with the installation script goes wrong, that wouldn’t be indeed very helpful. That’s the first point! You may need a thousands of installation scripts for the thousand use cases. If you don’t hit the use case for 100 %, it is presumable that something will go wrong.
just 2 thoughts:
The installerscript written by Alexander Jackson writes a very very usefull log. If someone post this log, i thing the proplem could be solved in allmost all cases much better than now.
A good Installerscript ensures that the basic settings and dependencies are given.
We need a much better, good structured manual too. It is important, that if there are any problems - we can read and maybe understand what is going wrong.
Only BOTH will give a much better experience for custummers, admins and users!
I’m sorry for the delay. I was tight of work, that happens from time to time.
But now I wrote some chapters to get the whole thing started. I put it here: BestPractiseManual.md. I’d appreciate your comments about it. Of course it’s not finished, but it should show my idea about this How-To.