Jump to content

_Vault_

Clients
  • Posts

    67
  • Joined

  • Last visited

Reputation Activity

  1. Like
    _Vault_ got a reaction from AlexWebsites in Links Directory   
    Got also flagged for me. I had both:


     
    Deleted categories.php and the error flagged by the PHP8 scanner was gone.
  2. Thanks
    _Vault_ got a reaction from Adriano Faria in Links Directory   
    Got also flagged for me. I had both:


     
    Deleted categories.php and the error flagged by the PHP8 scanner was gone.
  3. Like
    _Vault_ reacted to Adriano Faria in Links Directory   
    I can't reproduce:
    Not sure why it is pointing on a file called CATEGORIES.PHP, when the right one is CATEGORY.PHP. I should have changed that in some point, so it's a FALSE positive there. Anyway, if you have FTP access to your server, access the applications / links / api / and see if you have category.php there. If you have it AND also have categories.php, delete categories.php and you're fine.
  4. Like
    _Vault_ got a reaction from Marc Stridgen in Uploaded images, sideways (iOS)   
    For me as well
  5. Thanks
    _Vault_ reacted to Adriano Faria in Move banned members to group   
    Ok, that’s up to IPS indeed. I thought you were thinking it was a feature in the resource. My bad. 👍
  6. Like
    _Vault_ got a reaction from Jim M in Error 500 after Upgrade to 4.6.12   
    Thank you both @Jim M and @Adriano Faria for the tip with the recovery mode and how to use it.
    The plugin causing the error was:

    Back To Top  1.0.5
    By Pete Treanor
    http://invisionfocus.com

    After enabling the plugins one by one, and clearing the cache after each one, I was able to identify it. Luckily it's one that I can easily spare.   Thanks again! 🙂
  7. Like
    _Vault_ got a reaction from Adriano Faria in Error 500 after Upgrade to 4.6.12   
    Thank you both @Jim M and @Adriano Faria for the tip with the recovery mode and how to use it.
    The plugin causing the error was:

    Back To Top  1.0.5
    By Pete Treanor
    http://invisionfocus.com

    After enabling the plugins one by one, and clearing the cache after each one, I was able to identify it. Luckily it's one that I can easily spare.   Thanks again! 🙂
  8. Haha
    _Vault_ got a reaction from Sonya* in 504 Gateway Timeout when importing Language File   
    Thanks Sonya, actually I was installing your language pack and it has helped indeed 🙂 I was able to install it successfully now!
  9. Like
    _Vault_ reacted to Sonya* in 504 Gateway Timeout when importing Language File   
    These lines in my nginx configuration have helped to overcome this:
    proxy_connect_timeout 180s; proxy_send_timeout 180s; proxy_read_timeout 180s; fastcgi_send_timeout 180s; fastcgi_read_timeout 180s; I use Plesk and have a special field, where I can put this. It just a hint, that may help.  I am not a server expert, so do not ask me, how to add it to your server. 😊
  10. Thanks
    _Vault_ reacted to bfarber in Redis, bgsave   
    There is no requirement for Redis to persist data if restarted. Redis is used as a temporary cache. Any data lost does not represent a problem for the community software with a very minor exception not worth worrying about - you have the option to store "topic views" in Redis that are accumulated for a short period of time, and then they are saved to the MySQL database by a task periodically. If data does not persist, you might lose out on some topic views being recorded. This is probably not a concern if you are looking at fine tuning Redis persistance for performance in 99% of cases.
  11. Like
    _Vault_ reacted to bfarber in Redis, bgsave   
    You can restart Redis at any time - this should not log users out.
  12. Thanks
    _Vault_ reacted to CoffeeCake in Lazy load profile pictures on IPS 4.5   
    One day, future time traveler, 4.6 will appear. Until that day, here's a plugin that does what @Gabriel Torres documented for you for 4.5.
     
    Lazy Load Images.xml
    Submitted to Marketplace as a free resource for those that like the Marketplace thing:
     
  13. Thanks
    _Vault_ reacted to Makoto in Setting up a secure Nginx+PHP-FPM installation for IPS4   
    Nginx Server Installation Guide
    This is a guide for those interested in learning how to set up a secure, high performance Invision Power Suite installation using Nginx and PHP-FPM. Everything written here was done so with a focus on security, maintainability, and adherence to best practices. The information provided is the result of years of personal experience, research and testing.
    The steps listed have been tested to work on CentOS 7 and Debian Wheezy. If you run into any problems with your distribution, please submit as detailed of a report as you can below.
    Warning / Requirements
    This guide is intended for intermediate users and assumes you have at least a decent understanding of the Linux operating system. Please do not blindly attempt to run these commands on an active server. If you are replacing an existing Nginx installation, the easiest thing to do is make a backup of your configuration files, then purge/uninstall your existing Nginx installation before re-installing using the Nginx repository listed below.
      Be responsible. Test locally before trying to set anything up in production. The information and resources below are provided "as is", with no guarantee of support, and without warranty of any kind.
    1. Installing Nginx
    When installing Nginx on CentOS or Debian based systems, I recommend utilizing the official Nginx repository so you can keep up to date with the latest releases straight from the developers.
    Please follow the instructions on the official Nginx website to set this repository up on your system:
    http://nginx.org/en/linux_packages.html
    After importing the repository, go ahead and install Nginx.
    CentOS 7
    yum install nginx Debian / Ubuntu
    apt-get update apt-get install nginx 2. Configuring Nginx
    Once you have Nginx up and running, you can move on to the configuration. Open /etc/nginx/nginx.conf and make sure it matches the following configuration,
    user nginx nginx; pid /var/run/nginx.pid; worker_processes auto; worker_priority -10; events { worker_connections 1024; } http { ## # Basic Settings ## default_type application/octet-stream; keepalive_timeout 30; sendfile on; tcp_nodelay on; tcp_nopush on; ## # Logging Settings ## log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; #access_log /var/log/nginx/access.log main; access_log off; error_log /var/log/nginx/error.log error; ## # Gzip Settings ## gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; ## # Configuration Includes ## include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } Notice
    The "auto" worker_processes value is only supported in Nginx versions 1.2.5 (stable) / 1.3.8 (mainline) and up. If you are using an older version, you will need to manually specify a value instead.
    There are just a few things to note in detail here.
    First, we have changed our worker_processes from the default of 1 to auto. This will automatically assign workers equal to the number of cores your server has.
    Second, we have set the worker_priority of Nginx to -10. This is a small change that simply gives your web server higher CPU scheduling priority over other processes on your server.
    Finally, we have enabled the sendfile, tcp_nodelay and tcp_nopush directives to improve performance.
    3. Structuring your Nginx configuration files
    If you're going to be managing your configuration files manually, it's particularly important to have a good, solid configuration structure in place.
    The default layout of your /etc/nginx directory may vary a bit depending on your distribution. I personally recommend setting up and using a basic structure like this:
    /etc/nginx/ ? conf.d - Global configuration directives to be loaded automatically when Nginx is started. ? mime_types.conf - Universal mime type associations for file extensions. ? includes - Common configuration snippets to be included in server or location blocks as needed. ? ips - Common configuration snippets designed for use on IPS installations. ? protect_upload_directories - Configuration include used to prevent execution of PHP scripts in writable upload directories. ? allow_only_admins - Configuration include used to restrict location block access to server administrators. ? cache_static_files - Contains a location block used to automatically apply cache headers to static resources. ? deny_dotfiles - Contains a location block used to deny requests to dotfiles (eg; .htpasswd). ? php_fastcgi_params - Basic FastCGI configuration for PHP-FPM. ? php_fpm_status - Contains a location block used for enabling admin only access to the php_fpm_status URI. ? stub_status - Contains a location block used for allowing admins to access basic information about the web server. ? ... - May also contain various other includes provided by Nginx and/or your distribution. ? scripts - Contains various helper scripts for common Nginx related tasks. ? create - Creates configuration and domain directories for a new virtual host. ? disable - Removes configuration symlinks for a single domain or a domain and all its subdomains. ? enable - Creates a configuration symlink for a specified domain. ? fixperms - Automatically sets/fixes file ACL permissions for a specified domain. ? provision - Run once after installing Nginx to rebuild the Nginx configuration directory. ? sites-available - Contains all available virtual host configurations. (Structure: sites-available/{domain}/{subdomain-or-root}.conf) ? default - Default/"localhost" configurations. ? root.conf - The default configuration used for unconfigured virtual hosts. ? sites-enabled - Contains symlinks to enabled virtual hosts in /etc/nginx/sites-available, (Structure: sites-available/{domain}) ? default -> /etc/nginx/sites-available/default/root.conf - Default virtual host. ? ssl - Contains SSL keys and certificates for virtual hosts. Keys should be owned by root:nginx with no public access (chmod 0640). ? nginx.conf - The primary Nginx configuration file. Info
    You won't need to reconfigure everything above manually. A helper script will be provided at the end which can automatically provision everything for you.
    If you've worked with Apache before, you should feel pretty at home with this setup. You store configurations for virtual hosts in sites-available, then create symlinks to those configuration files in sites-enabled to actually enable them.
    To provide a quick example, here is how you would enable a virtual host manually (you won't need to do this manually if you use the helper scripts, but you should still know how),
    $ ln -vs /etc/nginx/sites-available/example.org/root.conf /etc/nginx/sites-enabled/example.org $ ln -vs /etc/nginx/sites-available/example.org/foo.conf /etc/nginx/sites-enabled/foo.example.org In sites-available, every domain has its own directory. Inside those directories are the virtual host configurations relevant to that domain, which are named by their subdomains (or "root" for www/no subdomain).
    When symlinking configurations in sites-enabled, you just use the raw domain name for the symlinks filename.
    $ ls -l /etc/nginx/sites-enabled/ lrwxrwxrwx. 1 root nginx 44 Dec 20 11:23 example.org -> /etc/nginx/sites-available/example.org/root.conf lrwxrwxrwx. 1 root nginx 44 Dec 20 11:23 foo.example.org -> /etc/nginx/sites-available/example.org/foo.conf $ rm -i /etc/nginx/sites-enabled/foo.example.org rm: remove symbolic link `/etc/nginx/sites-enabled/foo.example.org'? y This way, you get the best of both worlds. When you want to see which domains are enabled, you can just list the /etc/nginx/sites-enabled directory and everything is displayed in one place. When you need to review the virtual hosts for a domain, your configuration files remain efficiently categorized for sorting.
    I've written a script that will automatically provision your Nginx directory using the above structure, so you shouldn't need to do any of this manually. To get things rolling, just run the following commands,
    cd /etc/nginx/ wget https://github.com/FujiMakoto/nginx-helpers/releases/download/v0.1/scripts.tar.gz tar -xzvf scripts.tar.gz rm -f scripts.tar.gz /etc/nginx/scripts/provision After running the provisioner, you should be left with a setup roughly identical to the one above.
    If you have vim installed prior to running the provisioner, you will also be prompted to automatically download and install syntax highlighting for Nginx configuration files. This is a very nice feature to have if you're a vim user.
    Once you have everything provisioned, go ahead and restart Nginx and try and access your servers IP address through your web browser. You should see a generic Nginx welcome page. If you don't / if you get an error when restarting nginx, make sure you've updated the nginx.conf configuration properly and try again.
    4. Creating your first virtual host
    Now that you have a good configuration structure to work with, we can move on to creating our first IPS virtual host. To start, go ahead and set up a new directory for your domain name (naturally replacing yourdomain.com with your actual domain name),
    mkdir /etc/nginx/sites-available/yourdomain.com Next, go ahead and create a configuration file in the directory you made above. This should be named root.conf if your IPS installation is located on yourdomain.com / www.yourdomain.com, otherwise use the subdomain as the filename (for example, use community.conf for community.yourdomain.com).
    Inside of this file, insert the following configuration template,
    upstream php_backend { server unix:/var/run/php-fpm_webapp.sock; } server { # Basic server configuration listen 80; server_name yourdomain.com www.yourdomain.com; root /srv/http/yourdomain.com/root/html; index index.php; # Maximum allowed upload size client_max_body_size 100M; # Logging #access_log /srv/http/yourdomain.com/root/logs/access.log.gz combined gzip flush=5m; error_log /srv/http/yourdomain.com/root/logs/error.log error; # Friendly URL "rewrite" rules location / { try_files $uri $uri/ @ips; } # Configuration includes include /etc/nginx/includes/ips/protect_upload_directories; include /etc/nginx/includes/deny_dotfiles; include /etc/nginx/includes/stub_status; include /etc/nginx/includes/php_fpm_status; # Assign cache headers to static files location ~* ^.+\.(?:jpg|jpeg|gif|css|png|js|ico|xml|htm|swf|cur)$ { # If the static resource doesn't exist, pass off to IPS' 404 handler try_files $uri @ips404; access_log off; expires 2w; } # Lock down access to the AdminCP location ~ ^/admin/.+\.php$ { #allow 127.0.0.1; #deny all; #auth_basic "This page is restricted to administrators"; #auth_basic_user_file $document_root/admin/.htpasswd; try_files $uri @ips404; include /etc/nginx/includes/php_fastcgi_params; fastcgi_pass php_backend; } # Execute the requested PHP script if it exists, otherwise pass off to IPS location ~ \.php$ { try_files $uri @ips; include /etc/nginx/includes/php_fastcgi_params; fastcgi_pass php_backend; fastcgi_buffers 38 4k; fastcgi_buffer_size 16k; } # Pass off not found errors to IPS' 404 handler location @ips404 { include /etc/nginx/includes/php_fastcgi_params; fastcgi_pass php_backend; fastcgi_param SCRIPT_FILENAME $document_root/404error.php; fastcgi_param SCRIPT_NAME 404error.php; } # Send rewritten requests directly to IPS location @ips { include /etc/nginx/includes/php_fastcgi_params; fastcgi_pass php_backend; fastcgi_param SCRIPT_FILENAME $document_root/index.php; fastcgi_param SCRIPT_NAME /index.php; fastcgi_buffers 38 4k; fastcgi_buffer_size 16k; } } Virtual host configuration
    There are naturally some things you will need adjust here. We'll go through these in the order of which they appear. Once that's out of the way, we'll explain a bit how everything you see works.
    Server Name
    This one is obvious. Replace yourdomain.com with your actual domain name. If you are using a root level domain, be sure you add both the www/non-www variants.
    Root
    This, as you've probably already figured out, is the root path to your IPS installation. I recommend storing all of your applications in /srv/http and keeping to a/srv/http/{domain}/{subdomain} directory structure (similar to how our Nginx configuration files are managed).
    Client Max Body Size
    Self-explanatory. You should adjust this value to at least the maximum upload size you allow in IPS. You will need to remember to keep this value in sync with PHP's configured max_upload_size as well, otherwise your uploads will end up restricted to whichever setting is the lowest.
    AdminCP Location
    If you have renamed your AdminCP by following the instructions in the IPS security center, you will need to replace "admin" in the admin location block with the actual name of your admin directory. You can also enable IP based restrictions in this location block by uncommenting the allow and deny lines. You'll probably want to go ahead and add your local IP address as an allow line now if you do this. You can also set up .htpasswd based restrictions with the other two lines. For more information on how to do that, follow the instructions listed here.
      "Rewrite" rules and named location blocks
    Quite often, when looking up guides or examples for Nginx PHP configurations online, you'll see examples that simply pass every request ending with .php to FastCGI/PHP-FPM and be done with it.
    Don't do this, it is really a bad way to configure your server. Most prominently because it opens the potential for a serious security vulnerability, and while modern releases of PHP-FPM protect against this vulnerability by default, it only exists as a protection for misconfigured web servers. You shouldn't rely on it.
    By taking full advantage of Nginx's named location blocks and try_files processing, we are able to provide a clean and elegant configuration layout that is both secure and fast. In order to really understand how everything here works in detail, you'll need to dig into Nginx's documentation and familiarize yourself with how the location and try_files configuration directives work.
    Configuration Includes
    When running the provisioner script provided above, you'll automatically download a few simple but useful include files for Nginx. You can also also access them directly online here, each include file provides a bit of documentation explaining what it's for.
    In summary, the four includes we use here provide IPS' "Protect Writeable Folders From Dangerous Files" security recommendation for Nginx, block browser access to dotfiles (which is very important if you store a .htpasswd file in your AdminCP directory for HTTP authentication), and finally enable access to the ngx_server_status and php_fpm_status pages for registered server administrators.
    5. Setting up your web directory
    Now that we have a working virtual host for our IPS installation, it's time to set it up. As I mentioned above, I recommend storing your web files in /srv/http. Naturally, you don't have to do it that way. You are free to store your installations wherever you want, it will just require some additional work on your part to set everything up if you do use a different location.
    Why not /var/www?
    /var/www is a common place for http data to be stored, mostly because it is usually the default configured path for Nginx and Apache. However, while this is often the usual place for web data, it's not actually a standardized configuration. /var is best reserved (as its name implies) for variable files which change over time, such as log files.
    Why not /home/user/public_html?
    This setup is actually fine for shared hosting environments and may make the most sense in such a situation. However, there's no reason to use it outside of that. From a security perspective, I would also advise against hosting your IPS installation under your primary user account. In the absolute worst case scenario that your SSH credentials are compromised and you've followed this guides recommendations (also assuming you have a properly configured server), your installation files and data would still be protected.
    Why /srv/http?
    I personally use and recommend /srv/http as it is FHS compliant. The /srv directory is the only standardized directory specifically made for hosting service files like this. If you are already used to another way of doing things and don't want to change, you are again free to use whatever kind of configuration you like.
      We can use another helper script to take care of constructing the web directories for us, but if you decide not to use the default /srv/http path, you will need to edit the script below and modify HTTP_BASEDIR accordingly. Once that's done, go ahead and copy your IPS installation files into the html directory.
    mkdir -p /srv/http /etc/nginx/scripts/create yourdomain.com root 6. Locking down access to your web directory
    Optional
    While strongly recommended, it is not required that you follow the steps listed here. If you prefer not to (or are for some reason unable to) take advantage of ACL's, you will simply be responsible for setting up and managing permissions on your own. While outdated, you can still use the old Nginx+PHP-FPM server guide here as a reference for setting up decently secure UNIX permissions.
    In this step, I will be explaining how to set up and configure ACL (Access Control List) permissions for your web directories. If this is new to you, it may be a bit difficult to grasp at first, but I recommend sticking with it. ACL's are an incredibly powerful tool to have and make managing secure file permissions a lot easier in the long run.
    Go ahead and make sure the ACL utilities are installed now, they should be available through the acl package on most distributions. Next, test to make sure acl is enabled on your filesystem,
    touch acl_test setfacl -m "u:nginx:r--" acl_test getfacl acl_test rm acl_test If all is well, the above commands should run without error and you should see "user:nginx:r--" in the output returned by getfacl. If you do get an error, you likely need to enable acl on your filesystem now. To do this, replace /dev/sdXY in the command below with your actual filesystem device (e.g. /dev/sda1) and then try repeating the previous commands after,
    mount -o remount,acl / tune2fs -o acl /dev/sdXY Once you've confirmed acl's are working, you can go ahead and set the permissions for your IPS installation. Again, as long as you've configured Nginx using the provisioner script above, you will have access to a helper script to assist in doing this,
    /etc/nginx/scripts/fixperms yourdomain.com root After running the above command, you will be asked to provide a user for file ownership in your web directory. You can use whatever makes most sense to you here, a shortened version of your IPS communities name is a good example choice.
    Unless you plan on setting up and running multiple web applications under different PHP-FPM pools, it's reasonable to leave the default for the PHP-FPM user.
    When prompted for files to grant PHP modification access to, you should input conf_global.php only if this is a new IPS installation. Otherwise, leave this blank.
    When prompted for directories to grant PHP recursive write access to, input applications/ datastore/ plugins/ uploads/
    $ /etc/nginx/scripts/fixperms yourdomain.com root What user do you want to grant file ownership to? webapp What user does PHP-FPM run under for this virtual host? www-data Which individual files/directories should PHP be granted write access to? conf_global.php Which directories should PHP be granted recursive write access to? applications/ datastore/ plugins/ uploads/ Making sure all files and directories are owned by webapp Setting directory permissions to 0750 Setting file permissions to 0640 Setting default permissions for new files Granting Nginx user read-only access to all files and directories Granting PHP-FPM user read-only access to all files and directories Granting PHP-FPM user write access to conf_global.php Granting PHP-FPM user recursive write access in applications/ Granting PHP-FPM user recursive write access in datastore/ Granting PHP-FPM user recursive write access in plugins/ Granting PHP-FPM user recursive write access in uploads/ All site permissions updated successfully In the example above, first, we've set it so that everything in our web root is owned by the webapp user. Furthermore, permissions on all files and directories have been set in a way that completely prevents public access. This means that, at this point, no user other than webapp can see or read anything inside the web root.
    This is where we start using acl permissions. First, we run the following commands to grant the Nginx and PHP-FPM users read-only access to everything in our web directory,
    # Nginx setfacl -R -m "u:nginx:r-X" /srv/http/yourdomain.com/root setfacl -R -d -m "u:nginx:r-X" /srv/http/yourdomain.com/root # PHP-FPM setfacl -R -m "u:www-data:r-X" /srv/http/yourdomain.com/root setfacl -R -d -m "u:www-data:r-X" /srv/http/yourdomain.com/root The first commands (without the -d/--default flag) set the permissions on all existing files and directories. The second commands set the default permissions on all directories. This means any new files created inside your web directory will now automatically inherit the permissions you've configured.
    After that, we repeat the above commands for PHP-FPM (but with rwX permissions) in order to grant PHP write access to only the required files and directories. Note also that we use a capital X here when applying permissions recursively, that way only directories are made executable.
    With the following setup, you should never have a reason to use chmod 777 for anything. Furthermore, chmod 777 will also no longer work, as the ACL permissions for PHP-FPM will override it. You should instead use setfacl to set/remove permissions for PHP,
    # Make a file writable setfacl -m "u:www-data:rw-" conf_global.php # Make a file read-only setfacl -m "u:www-data:r--" conf_global.php # Recusrively make a directory and its contents writable setfacl -R -m "u:www-data:rwX" uploads/ setfacl -R -d -m "u:www-data:rwX" uploads/ # Recursively make a directory and its contents read-only setfacl -R -m "u:www-data:r-X" uploads/ setfacl -R -d -m "u:www-data:r-X" uploads/ For a good general overview of the acl utility commands and how they work, check out the Arch Wiki and Debian / CentOS documentation pages. For a more in-depth understanding of how setfacl works, read the manpages.
    7. Installing and configuring PHP-FPM
    Finally, it's time to install and configure PHP-FPM. Go ahead and install the required packages now,
    CentOS 7
    yum install php-fpm php-cli php-mysqlnd php-pdo php-gd php-mbstring php-xml # Only required if you use Imagick (which I recommend using over GD) yum install php-devel php-pear ImageMagick* pecl install Imagick echo "extension=imagick.so" > /etc/php.d/imagick.ini Debian / Ubuntu
    apt-get update apt-get install php5-fpm php5-cli php5-mysqlnd php5-curl php5-gd php5-imagick php5-json php5-mcrypt Afterwards, go ahead and delete the default PHP-FPM pool, as we will be replacing it with our own,
    CentOS 7
    rm /etc/php-fpm.d/www.conf nano /etc/php-fpm.d/webapp.conf Debian / Ubuntu
    rm /etc/php5/fpm/pool.d/www.conf nano /etc/php5/fpm/pool.d/webapp.conf Inside of this file, insert the following configuration template,
    [webapp] ;;;;;;;;;;;;;;;;;;;;; ; FPM Configuration ; ;;;;;;;;;;;;;;;;;;;;; ; Basic settings prefix = /var/run user = www-data group = www-data listen = php-fpm_webapp.sock listen.owner = www-data listen.group = www-data listen.mode = 0660 ; Process manager configuration pm = dynamic pm.max_children = 8 pm.start_servers = 2 pm.min_spare_servers = 2 pm.max_spare_servers = 4 pm.max_requests = 500 pm.status_path = /php_fpm_status ; Log slow requests (used for performance tuning, 0 = Off) request_slowlog_timeout = 0 slowlog = /srv/http/yourdomain.com/root/logs/php_slow.log ; Terminate unresponsive requests, this should match PHP's max_execution_timeout at a minimum request_terminate_timeout = 30s ; Don't allow executing arbitrary files as PHP scripts. YOU SHOULD NEVER DISABLE THIS. security.limit_extensions = .php ;;;;;;;;;;;;;;;;;;;;; ; PHP Configuration ; ;;;;;;;;;;;;;;;;;;;;; ; Make sure errors are not displayed publicly, error logging can be enabled as needed php_flag[display_errors] = off php_admin_flag[log_errors] = off php_admin_value[error_log] = /srv/http/yourdomain.com/root/logs/php_error.log ; Set the maximum upload size, memory limit and execution timeout php_admin_value[upload_max_filesize] = 100M php_admin_value[post_max_size] = 100M php_admin_value[memory_limit] = 128M php_admin_value[max_execution_time] = 30 ; PHP security directives, adjust open_basedir appropriately php_admin_value[cgi.fix_pathinfo] = 0 php_admin_value[disable_functions] = exec,system,popen,proc_open,shell_exec php_admin_value[open_basedir] = /tmp/:/usr/bin/:/srv/http/yourdomain.com/root/html/ As usual, go ahead and replace all references to yourdomain.com accordingly. If you allow uploads larger than 100M, you'll also want to tweak the upload_max_filesize and post_max_size PHP values.
    The main thing we want to look at here is the process manager configuration. There are three ways you can configure the process manager; static, dynamic, and ondemand. You can use whichever makes the most sense to you, but you'll likely be needing to watch and tune these settings a bit no matter which you choose, so there's no harm in experimenting with different configurations.
    Regardless of which you use, it's very important you don't try and set pm.max_children to a higher value than your server can handle. In the brief amount of profiling I could perform on IPS4 prior to writing this guide, my tests indicated that the average pool memory consumption for a mostly stock IPS install was around 32M per process. With the above configuration, this means that with all 8 children in use, PHP would be utilizing approximately 256M of memory.
    So, when tuning this value, you need to factor in how much memory you have know you can dedicate entirely to PHP. In the above example, you would need to dedicate at least 256MB to PHP with a bit of margin for error. This is what you should be doing for everything on your server. Also consider that 32M is only an example, the actual average memory requirement will vary from setup to setup, so it would be a good idea to do a bit of profiling yourself.
    As a final note, even if you have massive amounts of memory on hand, you still shouldn't set this value absurdly high. It can do more harm than good. Memory restrictions aside, a good starting value would probably be the number of cores your server has * 2. So, for a quad core server, 8 children would probably be a good starting point. If your community hosts a lot of attachments and handles a lot of PHP file transfers, you'll probably want to increase this value. Finding an optimal value here will take a bit of trial and error.
      So, what about Static?
    Good for very high traffic websites
    Static is the PM configuration I used for a long time. It's dead simple. With static, you don't need to specify start_servers, min_spare_servers or max_spare_servers. You just provide a number of child processes to spawn and they are all immediately spawned and kept alive and ready to handle requests at any moments notice.
    This sounds nice considering what I mentioned above. It offers better FPM performance, and since you're already dedicating that memory to PHP anyways, who cares if that memory is always in use?
    While there is a bit of truth to that, I probably would not recommend static for most installations anymore. I consider static particularly good for high traffic websites, or websites that receive a lot of very heavy intermittent traffic spikes. For most low to moderate traffic communities, I am more likely to recommend dynamic, and I explain why in more detail below.
      So, what about Dynamic?
    Good for moderate and low traffic websites
    Dynamic is probably the most common configuration. It's the middle ground between static and ondemand. With this setup, PHP always keeps a set number of child processes spawned and ready to handle incoming traffic. New child processes are spawned as traffic increases, old processes are destroyed as traffic lowers again. This is great for most web applications, as it avoids wasting memory.
    While you still should always tune assuming all processes are in use, keeping the unused processes cleaned up gives more free memory to the server, which can in return be used for disk caching to improve overall server performance.
    Dynamic also helps better protect against memory leaks. As unused processes are killed off, there's naturally less risk of memory leaks eating away at your memory pool. pm.max_requests normally helps protect against this, but it becomes less effective the more processes you keep spawned.
      So, what about Ondemand?
    Good for low traffic websites
    As its name implies, ondemand only spawns child processes on demand. This is similar to dynamic, however unlike with dynamic, ondemand does not keep any unused child processes active. When a request is made that spawns a new child process, a timeout is set. If no further requests are sent to that process within the timeout window, the process is destroyed.
    This could be beneficial for low traffic websites (particularly those on more memory constrained VPS'), but outside of that, there's probably not much of a reason to use it. Even for low traffic websites, keeping a small number of child processes spawned to handle new requests is usually good for performance.
      Wrapping up
    Once you have PHP-FPM configured, it's finally time to test everything out. Go ahead and enable your new virtualhost now,
    /etc/nginx/scripts/enable yourdomain.com root systemctl restart {nginx,php-fpm} Assuming no errors are returned, try and visit your community in your web browser. If all has gone well, you're done! If not, check your error logs, review your configuration, make sure permissions are properly applied, and make sure you have all the required PHP packages installed. If you still have problems, don't be afraid to ask for help, just be sure to provide a detailed description of your problem and include any relevant error log entries when doing so!
    Did you find this guide useful? You can show your support by sending a small tip, or by buying and reviewing one of my marketplace submissions! If that's not an option for you, you can also just tell me I'm awesome or something.
  14. Like
    _Vault_ got a reaction from Jordan Miller in Delete all "Banned" Users with 0 Posts   
    Thanks! That actually worked. 🙂
  15. Thanks
    _Vault_ reacted to Pavel Chernitsky in Delete all "Banned" Users with 0 Posts   
    Go into the members panel in the ACP, click the cog in the search bar, have it search for members with a 0 content count.
    when you get the results, click the "Banned" button above the results table. 
    From there you can prune the members found, or move them to another group (which if you delete, may(?) delete the users. I haven't tried it so I don't if it deletes all the users or just the group itself).
    I'm sure if it'll do the trick, but at least it'll allow you to round all the banned users up and then probably have an easier time doing what you need with them.
     
    screenshots for your convenience (the things you need are marked red; member names deleted for privacy):



     
     
  16. Thanks
    _Vault_ got a reaction from MEVi in Alternative to Amazon S3   
    For the same reason they don’t support Amazon SES and only 1 Mail Provider... god knows!
  17. Like
    _Vault_ reacted to James25 in Gab support   
    Would you please consider adding Gab to the Social Profiles section of General Configuration? Thank you.
  18. Sad
    _Vault_ got a reaction from SUBRTX in Delete all "Banned" Users with 0 Posts   
    A custom plugin for such a core functionality? I can search, move, delete members using all kinds of criteria. Why not banned?
  19. Like
  20. Like
    _Vault_ got a reaction from DamonT in /login - to check if a member is already logged in   
    Bump
  21. Like
    _Vault_ got a reaction from Adriano Faria in Links Directory   
    Today it worked. Maybe something was wrong with my server...not sure.
  22. Thanks
    _Vault_ reacted to bfarber in [Missing] Prune/Mass Move   
    Go to the forum management area in the AdminCP, click the dropdown arrow next to the forum, and choose to Move/Delete Content.
  23. Like
    _Vault_ got a reaction from SC36DC in Support for Amazon AWS SES   
    I’m switching to SES now as well, because the email costs at Sendgrid and others are too high for a non-profit community.
    IPS should really look into supporting SES via API. Right now I’ll use my own VPS/Postfix Relay to get it running and to keep latency low.
  24. Like
    _Vault_ got a reaction from AnonymousDev in Embed odysee.com   
    I would like to see support for embedding videos from odysee.com into the community.
  25. Like
    _Vault_ got a reaction from sobrenome in 4.5 and Video Attachments   
    Any feedback from staff on this? I think that video is a key feature, which is missing.
×
×
  • Create New...