Recherche avancée

Sur d’autres sites (4960)

• nginx : [emerg] invalid port in url "http://192.168.0.100:80/live" in nginx.conf - Restreaming OBS to LAN

  17 novembre 2018, par popek069

  I want to restream OBS to LAN. So I set up nginx server. The server receive stream from OBS using RTMP and restreams it to HTTP to view from another device.
  Streaming from OBS works, but when I start nginx I get an error

  PS C:\Users\popek\Downloads\nginx> .\nginx.exe -s reload
  
  nginx: [emerg] invalid port in url "http://192.168.0.100:80/live" in C:\Users\popek\Downloads\nginx/conf/nginx.conf:187

  I’m new to nginx and I’m running Windows 10, nginx server and OBS are on the same pc with ip 192.168.0.100
  I’d like to also reencode stream using ffmpeg if it’s possible. I know ffmpeg, I don’t know only how to set input and output.

  Config : (nginx.conf)

  #user  nobody;
  
  # multiple workers works !
  
  worker_processes  2;
  
  
  
  #error_log  logs/error.log;
  
  #error_log  logs/error.log  notice;
  
  #error_log  logs/error.log  info;
  
  
  
  #pid        logs/nginx.pid;
  
  
  
  
  
  events {
  
      worker_connections  8192;
  
      # max value 32768, nginx recycling connections+registry optimization = 
  
      #   this.value * 20 = max concurrent connections currently tested with one worker
  
      #   C1000K should be possible depending there is enough ram/cpu power
  
      # multi_accept on;
  
  }
  
  
  
  
  
  http {
  
      #include      /nginx/conf/naxsi_core.rules;
  
      include       mime.types;
  
      default_type  application/octet-stream;
  
  
  
      #log_format  main  '$remote_addr:$remote_port - $remote_user [$time_local] "$request" '
  
      #                  '$status $body_bytes_sent "$http_referer" '
  
      #                  '"$http_user_agent" "$http_x_forwarded_for"';
  
  
  
      #access_log  logs/access.log  main;
  
  
  
  #     # loadbalancing PHP
  
  #     upstream myLoadBalancer {
  
  #         server 127.0.0.1:9001 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9002 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9003 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9004 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9005 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9006 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9007 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9008 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9009 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9010 weight=1 fail_timeout=5;
  
  #         least_conn;
  
  #     }
  
  
  
      sendfile        off;
  
      #tcp_nopush     on;
  
  
  
      server_names_hash_bucket_size 128;
  
  
  
  ## Start: Timeouts ##
  
      client_body_timeout   10;
  
      client_header_timeout 10;
  
      keepalive_timeout     30;
  
      send_timeout          10;
  
      keepalive_requests    10;
  
  ## End: Timeouts ##
  
  
  
      #gzip  on;
  
  
  
      server {
  
          #listen       80;
  
          server_name  localhost;
  
  
  
          #charset koi8-r;
  
  
  
          #access_log  logs/host.access.log  main;
  
  
  
          ## Caching Static Files, put before first location
  
          #location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
  
          #    expires 14d;
  
          #    add_header Vary Accept-Encoding;
  
          #}
  
  
  
  # For Naxsi remove the single # line for learn mode, or the ## lines for full WAF mode
  
          location / {
  
              #include    /nginx/conf/mysite.rules; # see also http block naxsi include line
  
              ##SecRulesEnabled;
  
                ##DeniedUrl "/RequestDenied";
  
                ##CheckRule "$SQL >= 8" BLOCK;
  
                ##CheckRule "$RFI >= 8" BLOCK;
  
                ##CheckRule "$TRAVERSAL >= 4" BLOCK;
  
                ##CheckRule "$XSS >= 8" BLOCK;
  
              root   html;
  
              index  index.html index.htm;
  
          }
  
  
  
  # For Naxsi remove the ## lines for full WAF mode, redirect location block used by naxsi
  
          ##location /RequestDenied {
  
          ##    return 412;
  
          ##}
  
  
  
  ## Lua examples !
  
  #         location /robots.txt {
  
  #           rewrite_by_lua '
  
  #             if ngx.var.http_host ~= "localhost" then
  
  #               return ngx.exec("/robots_disallow.txt");
  
  #             end
  
  #           ';
  
  #         }
  
  
  
          #error_page  404              /404.html;
  
  
  
          # redirect server error pages to the static page /50x.html
  
          #
  
          error_page   500 502 503 504  /50x.html;
  
          location = /50x.html {
  
              root   html;
  
          }
  
  
  
          # proxy the PHP scripts to Apache listening on 127.0.0.1:80
  
          #
  
          #location ~ \.php$ {
  
          #    proxy_pass   http://127.0.0.1;
  
          #}
  
  
  
          # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
  
          #
  
          #location ~ \.php$ {
  
          #    root           html;
  
          #    fastcgi_pass   127.0.0.1:9000; # single backend process
  
          #    fastcgi_pass   myLoadBalancer; # or multiple, see example above
  
          #    fastcgi_index  index.php;
  
          #    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
  
          #    include        fastcgi_params;
  
          #}
  
  
  
          # deny access to .htaccess files, if Apache's document root
  
          # concurs with nginx's one
  
          #
  
          #location ~ /\.ht {
  
          #    deny  all;
  
          #}
  
      }
  
  
  
  
  
      # another virtual host using mix of IP-, name-, and port-based configuration
  
      #
  
      #server {
  
      #    listen       8000;
  
      #    listen       somename:8080;
  
      #    server_name  somename  alias  another.alias;
  
  
  
      #    location / {
  
      #        root   html;
  
      #        index  index.html index.htm;
  
      #    }
  
      #}
  
  
  
  
  
      # HTTPS server
  
      #
  
      #server {
  
      #    listen       443 ssl spdy;
  
      #    server_name  localhost;
  
  
  
      #    ssl                  on;
  
      #    ssl_certificate      cert.pem;
  
      #    ssl_certificate_key  cert.key;
  
  
  
      #    ssl_session_timeout  5m;
  
  
  
      #    ssl_prefer_server_ciphers On;
  
      #    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  
      #    ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:ECDH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!eNULL:!MD5:!DSS:!EXP:!ADH:!LOW:!MEDIUM;
  
  
  
      #    location / {
  
      #        root   html;
  
      #        index  index.html index.htm;
  
      #    }
  
      #}
  
  
  
  }
  
  
  
  
  
  rtmp {
  
          server {
  
                  listen 1935;
  
                  chunk_size 4096;
  
  
  
                  application live {
  
                          live on;
  
                          record off;
  
                          hls on;
  
                          push http://192.168.0.100:80/live ;
  
                  }
  
          }
  
  }

• Anomalie #3017 : Gestion des versions de plugins

  18 avril 2020, par RastaPopoulos ♥

  Je passe ce ticket en anomalie, car il s’agit à mon sens très clairement d’un bug (et un gros) : l’ergonomie aussi peut être buguée.

  Récemment, en peu de temps, plusieurs plugins ont eu des problèmes car les utilisateurs ont eu l’invitation de migrer à la dernière version alors qu’il y avait un saut de branche majeure (le X), sans aucun message de warning nulle part : spipr, saisies, prix… Et cela occasionne clairement des gros problèmes pour les gens, et donc bien du bug. Et encore, il ne s’agissait pas de mises à jour modifiant la base de données… là impossible même de revenir en arrière.

  Je pense qu’il faut profiter de ce ticket déjà existant, pour réaffirmer que c’est un bug et réfléchir à une ergonomie cohérente quelque soit les différents endroits : liste des plugins et icône-bouton d’annonce de mise à jour, recherche des plugins et comment on voit les différentes versions, etc.

  Je décris en texte, on verra si j’ai le temps de faire une maquette un jour…

  Vue des plugins actifs :¶

  C’est le cas le plus courant qui peut casser des choses chez les gens.
  - L’indication de mise à jour classique ne devrait s’afficher que pour les mises à jour Y et Z
  - Éventuellement un autre bouton différent indiquerait qu’il y a une mise à jour majeure X
  - Les mises à jour quelles qu’elles soient (mineures ou majeures) ne devraient se voir que si l’état est aussi stable ou plus stable que l’actuel (c’est déjà le cas je crois)
  - Parfois dans les releases il y a une mise à jour dans la même branche X et une autre changeant de X, dans ce cas on verrait bien deux indications et deux boutons différents
  - Une option générale de SVP pourrait permettre de choisir si on signale les mises à jour majeure ou pas (si non, seules Y et Z seront signalées)
  - Lorsqu’on choisit de mettre à jour à une version majeure supérieure, alors il devrait y avoir un méchant message ATTENTION, indiquant ce qu’on s’apprête à faire, ce qui permet d’annuler. Dans la phrase indiquant cela, il pourrait y avoir un lien vers la doc de la version majeure supérieure qu’on s’apprête à mettre. (Attention, vous allez changer la version majeure du plugin Patates en 3.3.3. Pensez à vérifier que cela ne va pas casser votre site : lien vers la doc)
  - Pour les actions de masse, pareil, ça devrait afficher les mêmes messages, mais plusieurs à la fois dans la même boite.

  Au passage : comme on le voit, parfois il est possible qu’on ait besoin d’ajouter des actions supplémentaires aux plugins. Il serait sûrement profitable de revoir une organisation cohérente des boutons comme discuté dans ce ticket : #4429 (et non pas certains en picto, certains en hover, etc). Notamment aussi car c’est toujours mieux quand on arrive à avoir des labels (d’autant plus si on doit différencier mise à jour mineure et majeure).

  Vue des plugins présents inactifs :¶

  On ne parle ici que des plugins non actifs ayant déjà une version activée (les autres on s’en fiche, ya rien à dire c’est une installation classique). Si on les a téléchargé et que c’est bien compat avec la version SPIP générale, on doit toujours les voir, seuls les obsolètes sont cachés par défaut.

  - Si dans les inactifs il y a une version supérieure mais mineure d’un plugin déjà actif, on le voit et on peut l’activer et aucun message particulier
  - S’il y a une version supérieure majeure d’un plugin déjà actif, on doit le voir aussi mais dans son cadre, il pourrait déjà y avoir une indication que ce plugin est déjà en cours d’utilisation et que cette version est un changement majeur. Et ensuite quand on essaye de l’activer, on devrait avoir le même message ATTENTION que décrit précédemment dans la boite qui s’ouvre.
  - Contrairement au premier onglet, là on doit voir aussi les versions même si l’état est moins stable (si ya un "test" alors que celui actif est "stable") : si on l’a téléchargé c’est qu’on veut le voir et pouvoir l’activer
  - On ne voit pas les versions plus petites que celles actives, car certaines plugins ont des structures de base, et là ça peut pas marcher de revenir en arrière. Celles là sont cachées si une version plus haute est active, mais on les voit si jamais installé par contre.

  Recherche des plugins :¶

  Actuellement l’interface ne montre que la dernière version, ce qui ne va pas du tout. De plus quand un plugin est déjà installé, ce plugin sort bien dans les résultats de recherche (avec "déjà installé") mais impossible de le télécharger même si la version indiquée dans la recherche est supérieure à celle en cours.

  Pour cet onglet, c’est plus que des corrections, il faudrait vraiment refaire pour voir au moins la dernière version de chaque X (voire de chaque X.Y) de chaque plugin. Que ce soit pour des plugins qu’on a pas du tout et pour des plugins déjà installés.

  Si j’ai le plugin Patates 3.13.0 installé, et qu’il a plusieurs mises à jour de plusieurs branches, alors dans la recherche je devrais voir :
  - La version 4.0.2 (avec un Attention)
  - La version 3.15.1
  - La version 3.13.4

  Si le plugin n’est pas du tout installé (et n’a jamais été installé ou a été bien désinstallé, bref : qu’il n’a plus son "base_version" du tout !) alors on devrait voir plus, et voir aussi la 2.4.5 etc, si on sait qu’on veut installer telle plus vieille version.

  On pourrait voir un bloc par plugin, et à l’intérieur, au lieu d’une seule case à cocher, sous le titre et slogan, on aurait une liste des versions, chacune avec sa case à cocher.

• Long Overdue MediaWiki Upgrade

  5 février 2014, par Multimedia Mike — General

  What do I do ? What I do ? This library book is 42 years overdue !
  I admit that it’s mine, yet I can’t pay the fine,
  Should I turn it in or should I hide it again ?
  What do I do ? What do I do ?

  I internalized the forgoing paean to the perils of procrastination by Shel Silverstein in my formative years. It’s probably why I’ve never paid a single cent in late fees in my entire life.

  However, I have been woefully negligent as the steward of the MediaWiki software that drives the world famous MultimediaWiki, the internet’s central repository of obscure technical knowledge related to multimedia. It is currently running of version 1.6 software. The latest version is 1.22.

  The Story So Far
  According to my records, I first set up the wiki late in 2005. I don’t know which MediaWiki release I was using at the time. I probably conducted a few upgrades in the early days, but that went by the wayside perhaps in 2007. My web host stopped allowing shell access and the MediaWiki upgrade process pretty much requires running a PHP script from a command line. Upgrade time came around and I put off the project. Weeks turned into months turned into years until, according to some notes, the wiki abruptly stopped working in July, 2011. Suddenly, there were PHP errors about “Namespace” being a reserved word.

  While I finally laid out a plan to upgrade the wiki after all these years, I eventually found that the problem had been caused when my webhost upgraded from PHP 5.2 -> 5.3. I also learned of a small number of code changes that caused the problem to go away, thus kicking the can down the road once more.

  Then a new problem showed up last week. I think it might be related to a new version of PHP again. This time, a few other things on my site broke, and I learned that my webhost now allows me to select a PHP version to use (with the version then set to “auto”, which didn’t yield much information). Rolling back to an earlier version of PHP might have solved the problem easily.

  But NO ! I made the determination that this goes no further. I want this wiki upgraded.

  The Arduous Upgrade Path
  There are 2 general upgrade paths I can think of :
  

  1. Upgrade in place on the server
  2. Upgrade offline and put the site back on the server

  Approach #1 is problematic since I don’t have direct shell access, though I considered using something like PHP Shell. Approach #2 involves getting the entire set of wiki files and a backup of the MySQL tables. This is workable since I keep automated backups of these items anyway.

  In fairly short order, I was able to set up a working copy of the MultimediaWiki hosted on a local Linux machine. Now what’s the move ? The MediaWiki software I’m running is 1.6.10. The very latest, as of this upgrade project is 1.22.2. I suppose it’s way too much to hope that the software will upgrade cleanly from 1.6.x straight to 1.22.x, but I guess it’s worth a shot…

  HA ! No chance. Okay, next idea is to march through the various versions and upgrade each in turn. MediaWiki has all their historic releases online, all the way back to the 1.3 lineage. I decided that the latest of each lineage should upgrade cleanly from anything in the previous version of lineage. E.g., 1.6.10 should upgrade cleanly to 1.7.3 (last in the 1.7 series). This seemed to be a workable strategy. So I downloaded the latest of each series, unpacked, and copied all the wiki files over the working installation and ran ‘php update.php’ in the maintenance/ directory.

  The process is tedious and not without its obstacles. I consider this penance for my years of wiki neglect. First, I run into the “PHP Parse error : syntax error, unexpected T_NAMESPACE, expecting T_STRING” issue, the same that I saw years ago after the webhost transitioned from PHP 5.2 -> 5.3. I could solve this by editing assorted files and changing “Namespace” -> “MWNamespace” (which is what MediaWiki did by version 1.13). But I would prefer not to.

  Instead, I downloaded the source for PHP 5.2 and compiled it in a separate directory, then called ‘/path/to/php/5.2/bin/php update.php’. Problem solved.

  The next problem is that a bunch of the database update scripts are specifying “Type=InnoDB”. This isn’t supported by modern MySQL databases. Now, it’s “Engine=InnoDB”. A quick search & replace at the command line fixes this for 1.6.x… and 1.7.x… and 1.8 through 1.12. Finally, at 1.13, it was no longer necessary. As a bonus, at 1.13, I was able to test the installation since Namespace had been renamed to MWNamespace. I would later learn that the table type modifications probably could have been simplified in by changing “$wgDBmysql4 = true ;” to “$wgDBmysql5 = true ;” somewhere in LocalSettings.php.

  Command line upgrading worked smoothly up through 1.18 series when I got a new syntax error :

  <br />
PHP Fatal error:  Call to a member function addMessages() on a non-object in /mnt/sdb1/archive/wiki/extensions/Cite.php on line 68<br />

  Best I could do was comment out that line. I hope that doesn’t break anything important.

  In the home stretch, the very last transition (1.21 -> 1.22) failed :

  PHP Fatal error :  Cannot redeclare wfProfileIn() (previously declared in 
  /mnt/sdb1/archive/wiki/includes/profiler/Profiler.php:33) in 
  /mnt/sdb1/archive/wiki/includes/ProfilerStub.php on line 25
  

  Apparently, this problem arises occasionally since 1.18. I found a way around it thanks to this page : Deleted the file StartProfiler.php. Who am I to argue ?

  Upon completing the transition to 1.22, the wiki doesn’t look correct– the pictures aren’t showing up. The solution was to fix the temporary directory via LocalSettings.php.

  Back To Production
  Okay, it all works again ! Locally, that is. How to get it back to the server ? My first idea was that, knowing that this upgrade process can succeed, try stepping through the upgrade process again, but tell the update.php scripts to access the database tables on multimedia.cx. This seemed to be working for awhile, even though the database update phase often took 4-5 minutes. However, the transition from 1.8.5 -> 1.9.6 took 75 minutes and then timed out. According to my notes, “This isn’t going to work.”

  The new process :

  1. Dump the database tables from the local database.
  2. Create a new database remotely (melanson_wiki_ng).
  3. Dump the database table into melanson_wiki_ng.
  4. Move the index.php file out of the wiki files directory temporarily (or rename).
  5. Modify the LocalSettings.php to talk to the new database.
  6. Perform a lftp mirror operation in order to send all the files up to the server.
  7. Send the index.php file and hope beyond hope that everything magically works.

  And that’s the story of how the updated MultimediaWiki came back online. Despite the database dump file being over 110 MB, it only tool MySQL 1m45s to transmit it all to the remote server (let’s hear it for the ‘–compress’ option). For comparison, inserting the tables back into a fresh local database took 1m07s.

  When the MultimediaWiki was first live again, it loaded, but ever so slowly. This is when I finally looked into optimization and found that I was lacking any caching. So as a bonus, the MultimediaWiki should be much faster now.

  Going Forward
  For all I know, I did everything described here in the hardest way possible. But at least I got it done. Unless I learn of a better process, future upgrades will probably look similar to this.

  Additionally, I should probably take some time to figure out what new features are part of the standard MediaWiki distribution nowadays.