Haack's Wiki

User Tools

Site Tools

Trace: • nextcloud
computing:pix3lfed

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
computing:pix3lfed [2026/03/01 19:06] – oemb1905computing:pix3lfed [2026/08/05 17:30] (current) – oemb1905
Line 160: Line 160:
   sudo -u www-data php artisan view:cache   sudo -u www-data php artisan view:cache
   sudo -u www-data php artisan optimize   sudo -u www-data php artisan optimize
 +  sudo -u www-data php artisan instance:actor
 +  sudo -u www-data php artisan import:cities
  
 === Step 4: Additional Apache Tweaks === === Step 4: Additional Apache Tweaks ===
Line 177: Line 179:
 Pixelfed has a nested ''.htaccess'' file inside ''public'' so let's ensure that Overrides are enabled globally. Let's open up ''sudo nano /etc/apache2/apache2.conf'' and change ''None'' to ''All'' in the appropriate sections (this matches the Override rule in the vhost). In the webroot block, or ''<Directory /var/www/>'', it should look like: Pixelfed has a nested ''.htaccess'' file inside ''public'' so let's ensure that Overrides are enabled globally. Let's open up ''sudo nano /etc/apache2/apache2.conf'' and change ''None'' to ''All'' in the appropriate sections (this matches the Override rule in the vhost). In the webroot block, or ''<Directory /var/www/>'', it should look like:
  
 +<code bash>
 <Directory /var/www/> <Directory /var/www/>
     Options Indexes FollowSymLinks     Options Indexes FollowSymLinks
-    AllowOverride **All**+    AllowOverride All ### NOTE "All" instead of "None" ###
     Require all granted     Require all granted
 </Directory> </Directory>
 +</code>
  
-Additionally, the Pixelfed website mentions that some users of apache might have difficulty with the default ''.htaccess'' file in ''public'' so they recommended changing it. My instance had trouble finding certain locations and directories unless I changed to their recommendation. Open up ''sudo nano /var/www/pixelfed/public/.htaccess'' and enter the recommendation as follows:+Additionally, the Pixelfed website mentions that some users of apache might have difficulty with the default ''.htaccess'' file in ''public'' so they recommended changing it. My instance indeed had trouble finding certain locations and directories unless I changed to their recommendation. Open up ''sudo nano /var/www/pixelfed/public/.htaccess'' and enter the recommendation as follows:
  
   <IfModule mod_rewrite.c>   <IfModule mod_rewrite.c>
Line 201: Line 205:
 First, let's create the unit file over in ''sudo nano /etc/systemd/system/pixelfed.service'' and inside that unit file, put something similar to the following: First, let's create the unit file over in ''sudo nano /etc/systemd/system/pixelfed.service'' and inside that unit file, put something similar to the following:
  
-  [Unit] +<code> 
-  Description=Pixelfed Horizon Queue Worker (Laravel Horizon) +[Unit] 
-  After=network.target apache2.service php8.4-fpm.service redis-server.service mariadb.service +Description=Pixelfed Horizon Queue Worker 
-  Wants=apache2.service php8.4-fpm.service redis-server.service mariadb.service +Documentation=https://laravel.com/docs/horizon 
-  [Service] +After=network.target apache2.service php8.4-fpm.service redis-server.service mariadb.service 
-  Type=simple +Wants=apache2.service php8.4-fpm.service redis-server.service mariadb.service 
-  User=www-data + 
-  Group=www-data +[Service] 
-  WorkingDirectory=/var/www/pixelfed +Type=simple 
-  ExecStart=/usr/bin/php artisan horizon +User=www-data 
-  Restart=on-failure +Group=www-data 
-  RestartSec=5s +WorkingDirectory=/var/www/pixelfed 
-  StandardOutput=journal +ExecStart=/usr/bin/php artisan horizon 
-  StandardError=journal +Restart=always 
-  NoNewPrivileges=yes +RestartSec=3 
-  PrivateTmp=true +StartLimitIntervalSec=0 
-  ProtectSystem=strict +StandardOutput=journal 
-  ProtectHome=yes +StandardError=journal 
-  ReadWritePaths=/var/www/pixelfed/storage + 
-  ReadWritePaths=/var/www/pixelfed/bootstrap/cache +# Security hardening (less restrictive than before) 
-  [Install] +NoNewPrivileges=yes 
-  WantedBy=multi-user.target+PrivateTmp=true 
 +ProtectSystem=full 
 +ProtectHome=yes 
 +ProtectKernelTunables=yes 
 +ProtectKernelModules=yes 
 +ProtectControlGroups=yes 
 +RestrictSUIDSGID=yes 
 +LockPersonality=yes 
 +RestrictRealtime=yes 
 + 
 +# Paths Horizon actually needs to write to 
 +ReadWritePaths=/var/www/pixelfed/storage 
 +ReadWritePaths=/var/www/pixelfed/bootstrap/cache 
 +ReadWritePaths=/tmp 
 + 
 +[Install] 
 +WantedBy=multi-user.target 
 +</code>
  
 After you create the unit file, let's reload the daemon, restart the service and check for any errors. Restart all services and check a web browser to see if the instance resolves after restarting the services. After you create the unit file, let's reload the daemon, restart the service and check for any errors. Restart all services and check a web browser to see if the instance resolves after restarting the services.
Line 234: Line 255:
   sudo systemctl reload apache2   sudo systemctl reload apache2
   sudo systemctl restart apache2 php8.4-fpm pixelfed.service redis-server   sudo systemctl restart apache2 php8.4-fpm pixelfed.service redis-server
 +  
 +Lastly, let's create our artisan workers so changes and updates happen automatically. Open up cron for www-data user with ''sudo crontab -u www-data -e'' and then enter the following:
 +
 +<code>
 +* * * * * cd /var/www/pixelfed && php artisan schedule:run >> /dev/null 2>&1
 +* * * * * cd /var/www/pixelfed && php artisan horizon:snapshot >> /dev/null 2>&1
 +* * * * * cd /var/www/pixelfed && php artisan horizon:terminate >> /dev/null 2>&1
 +</code>
  
 At this point, most essential lifts are done. As long as your landing page resolves, which it should by this stage, you can now move on to creating an admin user and then managing the instance via the GUI web panel: At this point, most essential lifts are done. As long as your landing page resolves, which it should by this stage, you can now move on to creating an admin user and then managing the instance via the GUI web panel:
  
 === Step 6: User Creation & Instance Management === === Step 6: User Creation & Instance Management ===
 +
 +Let's create the admin user:
  
   cd /var/www/pixelfed   cd /var/www/pixelfed
Line 254: Line 285:
   curl -s https://gnulinux.pics/.well-known/nodeinfo   curl -s https://gnulinux.pics/.well-known/nodeinfo
   curl -s https://gnulinux.pics/api/nodeinfo/2.0   curl -s https://gnulinux.pics/api/nodeinfo/2.0
 +  curl -s "https://gnulinux.pics/.well-known/webfinger?resource=acct:admin@gnulinux.pics"
   sudo -u www-data php artisan route:list | grep -i nodeinfo   sudo -u www-data php artisan route:list | grep -i nodeinfo
 +  
  
 For updating, something like the following is minimally required: For updating, something like the following is minimally required:
Line 291: Line 324:
 This little script just helps me refresh everything if/when changes or adjustments need to be made. Once the instance gets approved and/or I have resolved the well-known federation and/or discovery stuff, I will post an update. Thanks all and happy hacking !! This little script just helps me refresh everything if/when changes or adjustments need to be made. Once the instance gets approved and/or I have resolved the well-known federation and/or discovery stuff, I will post an update. Thanks all and happy hacking !!
  
- --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/03/01 18:02//+------------------------------------------- 
 + 
 +=== Debugging, Miscellaneous, Updates === 
 +From here forward, I post miscellaneous debugging. To fix images in DMs failing, as per github #5217, #5365, #5496, I edited the db to accept wrongly submitted null values from the bad DM code: 
 + 
 +  mysql -u root -p 
 +  USE pixel; 
 +  ALTER TABLE statuses MODIFY COLUMN caption TEXT NULL; 
 +  EXIT; 
 + 
 +This solves the issue and allows users to upload images inside their DMS. Here are the issues that helped me fix this: 
 + 
 +  * [[https://github.com/pixelfed/pixelfed/issues/5217|#5217]] 
 +  * [[https://github.com/pixelfed/pixelfed/issues/5365|#5365]] 
 +  * [[https://github.com/pixelfed/pixelfed/issues/5496|#5496]] 
 + 
 +I'm having an issue where the sql of the instance wrongly uses 19 for the re-issuance of the new client registration. Since this conflicts with 19 being used by the default personal client, it fails. After repeatedly messing with auto-increment according to github iALTER TABLE oauth_clients DROP PRIMARY KEY;ssues and seeing it fail once the keys and passport were re-initialized, I decided to change the entry to a varchar assignment instead, removing the conflict: 
 + 
 +  ALTER TABLE oauth_clients MODIFY id INT NOT NULL; 
 +  ALTER TABLE oauth_clients DROP PRIMARY KEY; 
 +  ALTER TABLE oauth_clients MODIFY id VARCHAR(255) NOT NULL; 
 +  ALTER TABLE oauth_clients ADD PRIMARY KEY (id); 
 +  DESCRIBE oauth_clients; #verify it changed properly 
 +  EXIT; 
 +  cd /var/www/pixelfed 
 +  sudo -u www-data php artisan passport:install --force 
 +  sudo -u www-data php artisan passport:keys --force 
 +  sudo /usr/local/bin/refresh.sh 
 +   
 +Once I did this, the ''passport:keys'' step no longer failed or barfed about row 19. I am worried about this lol, but at least the error is gone ;O. To assist actor status: 
 + 
 +  https://gnulinux.pics/i/actor 
 +  https://github.com/pixelfed/support/issues/183 
 +   
 +More coming ...  
 + 
 + --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/08/05 17:28//
computing/pix3lfed.1772392011.txt.gz · Last modified: by oemb1905

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3
GNU Free Documentation License 1.3 Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki