Search found 6301 matches: security

Searched query: +security

Return to advanced search

Nothing happened when click 'open terminal'?

It popped a window at first time and maybe I clicked 'deny' :x
I don't know if I missed some configurations or system security settings?
Can somebody tell me how to fix it? :(
by slash
16. January 2020 04:25
 
Forum: XAMPP for Mac OS X
Topic: Nothing happened when click 'open terminal'?
Replies: 0
Views: 325

Re: Wordpress

Nobbie wrote:Nein, das ist ein schönes Beispiel für Vergewaltigung der Statistik. Richtig ist diese Aussage: etwa ein Drittel der 10 Millionen meistbesuchten Webseiten sind mit Wordpress realisiert. Das ist die Statistik, die u.a. Heise veröffentlich hat und die kommt von irgendwelchen Amazon Servern. Habe ich vergessen, ist aber nicht so wichtig.

Stimmt auch nicht so ganz. Genau genommen stammt die Erhebung von W3Techs,com und die wiederum fragen per Crawler auf Basis einer von Alexa (einer Amazon Firma) basierenden Liste der (im 3 Monats Durchschnitt) 10 Millionen am meisten aufgerufenen Webseiten. Aber schon bei dem Begriff "Website" Unterscheiden sich W3Techs und Alexa voneinander, weshalb W3Techs sogar von "weniger als 10 Millionen" spricht. So werden Subdomains bei W3Techs zum Beispiel in der Regel nicht als unterschiedliche Websites gezählt.

W3Techs.com Statistiken werden in der IT Fachpresse relativ häufig zitiert. Das muss nicht zwingend bedeuten, dass die Statistik besonders realitätsnahe Werte liefert, aber W3Techs ist sehr offen dabei, wie die Werte zustandekommen. So erklärt W3Techs zum Beispiel auch, warum man sich auf die Top 10 Millionen beschränkt hat. Genaueres kann man hier (https://w3techs.com/technologies) und hier (https://w3techs.com/faq) nachlesen. Im Allgemeinen gelten die Statistiken von W3Techs als einigermaßen belastbar und repräsentativ, vorallem aber als Transparent.

Es gibt auch Statistiken die eine größere Datenbasis umfassen (Beispielsweise von buildwith mit über 50 Millionen Einträgen https://trends.builtwith.com/cms/traffi ... e-Internet). Zum Einen beschränkt sich diese aber auf Webseiten mit CMS, zum anderen wird hier nicht beschrieben, wie die Datenbasis zustandekommt und worauf sie basiert.

Nobbie wrote:Das klingt erst mal überzeugend. ABER: die Gesamtzahl aller Webseiten liegt geschätzt bei 1 Milliarde(!). Das knackt also schon mal hörbar laut, in obiger Statistik wurden also nur 1%(!) aller Websites ausgewertet.

Laut https://www.internetlivestats.com/watch/websites/ sogar bei über 1,7 Milliarden. Auch hier stellt sich wieder die Frage: Was gilt alles als Webseite? Ist eine geparkte Domain schon eine eigene Webseite? oder die Subdomain eines Wikipedia? oder gar jede als HTML Auslieferbare Webressource? Es gibt relativ genaue Aussagen über die Anzahl an registrierten Domains im Internet (begrenzte Anzahl an Registrare, ratierliche Reports). Die Zahlen liegen irgendwo im Dreistelligen Millionenbereich (~350 Millionen Second Level Domains). Bedeutet also, dass sich hinter jeder Domain im Durchschnitt 3-5 Webseiten verbergen (nach deiner bzw. der Definition von internetlivestats.com). Das soll nur eine Feststellung, keine Wertung sein.

Nobbie wrote:Das spiegelt u.a. meine Argumentation wieder, dass WordPress in den Händen von Profis sicherlich eingesetzt werden kann (und wird), aber was das für die vielen zig Millionen Seiten betrifft, die vom "kleinen Mann" erstellt wurden, das wissen wir nicht. Unter den ersten 1% aller Webseiten dürfte mehr oder mehr fast gar keine Seite des kleinen Mannes dabei sein.

Da stimme ich dir zu. Das was man sagen kann ist, dass alle großen Statistiken Wordpress einen großen Marktanteil zurechnen. Und natürlich sind die Top X Größten oder Frequentiertesten Webseiten für solche öffentlichen Statistiken viel interessanter. Für den Rest des Internets wissen wir es einfach nicht und daher kann man zu diesen keine Aussage treffen. Es gibt aber Faktoren, die es nahe legen, dass auch im Rest des Internets ein signifikanter Anteil an Wordpress Installationen zu finden ist, sei es weil es auf dem Berufsmarkt auf Grund der Nachfrage gesucht ist, aus interesse wie seine eigene Lieblingswebseite so arbeitet, oder als Programmieranfänger der mal schnuppert was das Internet so ausmacht. Man stößt unweigerlich auf Wordpress und damit auch auf eine große Zielgruppe von Menschen die das sicher mal ausprobieren oder Dauerhaft auch mit einer kleinen Webseite betreiben.
Ironischerweise ist auch die Existenz von unsicheren, schlampig Programmierten Plugins eher ein Indiz dafür, dass sich nichtnur Webprogrammierungsprofis mit Wordpress beschäftigen.

Nobbie wrote:Unabhängig davon, gibt es einen Zusammenhang zwischen Qualität (die Du hier annimmst) und Erfolg? Also erstens schreibst Du vorne ja auch, dass WordPress "gruselig" programmiert ist. Das ist ja nun ganz gewiss KEIN gutes Qualitätskriterium.

Ich schätze, Wordpress ist so gruselig programmiert, weil es ziemlich schnell gewachsen ist und dass vielleicht in einer Zeit, in der man versäumt hat saubere und sichere Schnittstellen für Plugins zu schaffen. Irgendwann war Wordpress so groß, dass man sich die Nutzerbasis nicht durch inkompatibilitäten resultierend aus umfassenden Refaktorisierungsmaßnahmen gefährden wollte. Windows ist auch gruselig programmiert mit vielen Altlasten und Abwärtskompatibilitäten. Da sehe ich also keinen Zusammenhang zwischen Qualität und Erfolg. Ich habe lediglich behauptet, dass ein System, dessen negatives Image dauerhaft größer ist als dessen nutzen am Open Source Markt (zumindest was freie Software betrifft) nicht über Jahre bestehen kann, wenn es Alternativen gäbe die mindestens dieselben Vorteile bieten bei weniger Nachteilen. Wordpress hat halt vieles richtig gemacht was die Verbreitung betrifft. Ich erinnere mich noch, als ich mich das erste Mal mit Wordpress beschäftigt habe. Damals war Wordpress ein reines Blog-CMS und die Blogger-Szene auch unter Jugendlichen und jungen Erwachsenen wuchs rasant. Niemand hätte Wordpress zu der Zeit als Shopsystem, oder Community-Board eingesetzt. Heutzutage kann man fast alles irgendwie mit Wordpress umsetzen.

Nobbie wrote:Bleibt die Frage, woher kommt der Erfolg? Einfache Antwort: weiß man nicht. Es gibt viele Beispiele, dass ein eigentlich minderwertiges Produkt Erfolg hat. Beispiele: das Videosystem VHS (von JVC) war in den siebziger Jahren nur eines von dreien. Sony hat mit Betamax und Philips mit Video2000 auch um die Gunst der Kunden gebuhlt. Das mit Abstand beste System (aus technischer Sicht, aus den verschiedensten Gründen) war Video2000 (konnte beidseitig die Kassette bespielen, konnte streifenfrei Suchlauf absolvieren), das zweitbeste war Betamax (hatte das beste Bild insgesamt, konnte aber nur einseitig abspielen). Das mit Abstand schlechteste System VHS hat sich durchgesetzt.

Ich weiß nicht inwieweit man kommerzielle Verbreitung mit Open-Source Software vergleichen kann, da spielen ja doch noch viele andere Faktoren der Marktwirtschaft eine Rolle. Aber dennoch finde ich die Geschichte zum Erfolg der VHS Kassette sehr interessant.

Nobbie wrote:Die Software WhatsApp hätte eigentlich nie irgendwo installiert werden dürfen, so schlecht (war) ist sie programmiert. Boshaft wird direkt die ganze Kontaktsammlung des Anwenders auf amerikanische Server gehievt, die Kommunikation erfolgte im Klartextmodus. WhatsApp hat interessanterweise auch in den USA nicht den gleichen Erfolg wie bei uns beispielsweise (habe ich auch erst kürzlich mit Staunen erfahren), das liegt wohl daran, dass Apple mit den iPhones den Großteil des US Markts kontrolliert und mit iMessage eine beliebtere Alternative anbietet. Hier bei uns hat sich Threema nie auch nur ansatzweise durchgesetzt, obwohl es um Lichtjahre die bessere Lösung war.

Die Deutschen sind in meinen Augen ein Volk der Unbekümmertheit, was die eigenen und fremden Daten betrifft. Es ist doch bequem, wenn der Messanger auf dieselbe Kontaktbasis zugreifen kann wie das Handy-Telefonbuch. Die Sicherheit von Threema geht zu Lasten der Bequemlichkeit. Aber ich denke, dass WhatsApp die kritische Nutzermasse schon weit überschritten hat als dass sich da in Absehbarer Zeit etwas dran ändern wird. Viele nutzen Whatsapp einfach aus dem Grund weil es fast jeder hat und mehr als einen Messanger Dienst zu benutzen ist unbequem.

Nobbie wrote:Ich sage ja nicht, dass WordPress keinen Nutzen hat. Aber die Philosophie der Plugins und dass sie ungewartet und ungeprüft in das Dictionary aufgenommen werden (Apple macht es genau anders herum, es kommen nur qualifizierte Apps in den Store, das ist durchaus vergleichbar), das ist eine Sauerei gegenüber dem kleinen Mann. Der dann solche "Reinigungsaktionen" durchziehen soll, wie ich es gestern auf einer Seite gelesen habe. Das ist eine Zumutung und deswegen kann ich nach wie vor WordPress nicht für den Laien empfehlen.

Nein, das ist nicht vergleichbar. IOS ist kein offenes Betriebssystem, der Apple Store ist die einzige Bezugsquelle von Apple Erweiterungen. Apple hat also die genaue Kontrolle darüber was mit ihren Geräten und der Software darauf passiert. Das ist das Komplette gegenteil der Open-Source Philosophie. Apple ist jetzt auch nicht gerade als das herzensgute gönnerische Unternehmen bekannt, dass keine Gewinne machen möchte und dem Kunden das bestmögliche Produkt zum für den Kunden bestmöglichen Preis verkaufen möchte.
Es gehört auch ein bisschen Skepsis dazu, wenn man ein Herstellerprodukt mit Drittanbietererweiterungen ergänzen möchte. Wenn dein Smartes Türschloss ungewollt jemandem die Tür öffnet, wirst du dich ja auch nicht bei dem Hersteller deiner Tür auslassen, oder bei dem Browser deines Vertrauens wenn du ein unsicheres Plugin zum Speichern deiner Passwörter verwendest.

Nobbie wrote:Ich bin weder ein Idiot noch ein Software Tölpel, meine Brüder auch nicht (die arbeiten alle in der IT Branche) und wir haben gemeinsam die WordPress Seite unserer Familie betreut und NATÜRLICH aktualisiert und gepflegt. Trotzdem hatten wir drei Mal das Pech, ein verseuchtes Plugin installiert zu haben (mein Bruder wusste defnitiv nicht, dass Plugins so ein Problem darstellen). Nachdem ich dann ein paar Tage im Internet geforscht und gelesen habe (und da ist mir bald schlecht geworden, was man da alles zu lesen bekommt, wie WordPress damit umgeht), habe ich beschlossen, WordPress rauszuschmeißen und alles selbst mit HTML und PHP zu programmieren. Seit dem haben wir Ruhe. Und wenn ich 20000 Bilder umbenennen muss, mache ich das unter Linux in der Shell oder benutze irgendeine Standardsoftware. Mit Sicherheit NICHT ein WordPress Plugin...

Das würde ich auch nie behaupten. Ich würde auch nicht behaupten, dass ich besser sichere Webanwendungen programmieren kann als ein Vollzeit Webanwendungsentwickler. Die Sicherheit von selbstentwickelten Webseiten basiert ja vornehmlich darauf, dass kaum einer sich die Mühe machen würde, dort nach Schwachstellen zu suchen (Kosten Nutzen). Das ist einfach nur eine Abwandlung von Security by Obscurity. Ich halte es für sehr Wahrhscheinlich auf 1000 Zeilen Code mehr Sicherheitslücken ungewollt einzuprogrammieren als die 50 Wordpress Core Sicherheits Experten auf 100000 Zeilen Code.
by Altrea
10. January 2020 14:34
 
Forum: Allerlei
Topic: Wordpress
Replies: 7
Views: 5201

Re: Apache Error: Apache shutdown unexpectedly.

I did have the same problem, I got in the Control Panel the next log text:

[
07:05:33 p. m. [main] Initializing Control Panel
07:05:33 p. m. [main] Windows Version: Enterprise 64-bit
07:05:33 p. m. [main] XAMPP Version: 7.4.1
07:05:33 p. m. [main] Control Panel Version: 3.2.4 [ Compiled: Jun 5th 2019 ]
07:05:33 p. m. [main] You are not running with administrator rights! This will work for
07:05:33 p. m. [main] most application stuff but whenever you do something with services
07:05:33 p. m. [main] there will be a security dialogue or things will break! So think
07:05:33 p. m. [main] about running this application with administrator rights!
07:05:33 p. m. [main] XAMPP Installation Directory: "d:\xampp\"
07:05:33 p. m. [main] Checking for prerequisites
07:05:34 p. m. [main] All prerequisites found
07:05:34 p. m. [main] Initializing Modules
07:05:34 p. m. [main] Enabling autostart for module "Apache"
07:05:34 p. m. [main] Enabling autostart for module "MySQL"
07:05:34 p. m. [main] Starting Check-Timer
07:05:34 p. m. [main] Control Panel Ready
07:05:34 p. m. [Apache] Autostart active: starting...
07:05:34 p. m. [Apache] Attempting to start Apache app...
07:05:34 p. m. [mysql] Autostart active: starting...
07:05:34 p. m. [mysql] Attempting to start MySQL app...
07:05:35 p. m. [Apache] Status change detected: running
07:05:35 p. m. [mysql] Status change detected: running
07:05:36 p. m. [Apache] Status change detected: stopped
07:05:36 p. m. [Apache] Error: Apache shutdown unexpectedly.
07:05:36 p. m. [Apache] This may be due to a blocked port, missing dependencies,
07:05:36 p. m. [Apache] improper privileges, a crash, or a shutdown by another method.
07:05:36 p. m. [Apache] Press the Logs button to view error logs and check
07:05:36 p. m. [Apache] the Windows Event Viewer for more clues
07:05:36 p. m. [Apache] If you need more help, copy and post this
07:05:36 p. m. [Apache] entire log window on the forums

]

1) I have already changed the ports to the suggested options in the forum for this issue (changing port in the config file for httpd.conf [from port 80 to 8080, there are 2 or 3 lines that have the 80 number] and for httpd-ssl.conf [from 443 to 10443 port, change all the 443 number for 10443], and I also changed this ports in the Control Panel at the "config" button and then in the "service and port settings"). Then I tried to start Apache alone from the command line using adminstrative rights ("executing as administrator" the "apache_start.bat" file in the xampp directory), and I got this:

[
Diese Eingabeforderung nicht waehrend des Running beenden
Bitte erst bei einem gewollten Shutdown schliessen
Please close this command only for Shutdown
Apache 2 is starting ...
AH00526: Syntax error on line 94 of D:/xampp/apache/conf/extra/httpd-xampp.conf:
Argument for 'Require all' must be 'granted' or 'denied'


Apache konnte nicht gestartet werden
Apache could not be started
Presione una tecla para continuar . . .
]

2) Certainlly, once I installed XAMPP, I first changed "httpd-xampp.conf" in line 93 (because I added a new line 94, and commented out the line original 93 with a "#" character) in order to access XAMPP fron other computer at my network:

[
Alias /phpmyadmin "D:/xampp/phpMyAdmin/"
<Directory "D:/xampp/phpMyAdmin">
AllowOverride AuthConfig
# Require local # the original line
Require all granted # added this new line for network access but now with problems
ErrorDocument 403 /error/XAMPP_FORBIDDEN.html.var
</Directory>
]

So I had to set to the original "Require local" line 93, and commented out my unaccepted "Require all granted". By now I have not solved this tiny issue. Apache works now but I can not take control from other computer in my network.

Al this, just to say that, it will be a good idea to try to execute from the command line, the "apache_start.bat" file in the xampp directory, I think you will get a better idea of your issue.

3) Tip: execute the Control Panel as administrator too, from the XAMPP directory use "xampp-control.exe", right-mouse-click over the file name at the file-manager and use "execute as administrator" option.

Regards.

Art.
by arturogr
06. January 2020 03:06
 
Forum: XAMPP for Windows
Topic: Apache Error: Apache shutdown unexpectedly.
Replies: 3
Views: 455

What should the .htaccess file in wp-admin: .htaccess tricks

hello dear all


What should the .htaccess file in wp-admin contain? I've read that this .htaccess file should password protect the wp-admin directory and I've also read that this can cause functionality problems. well if it comes to .htaccess security in general I am not to firm with the concepts - therefore i have gathered some infos.

I don't have specific experience with securing /wp-admin/ using .htaccess here a little list of some resources of different areas of interst regarding htaccess

- Hardening WordPress with .htaccess
- Password Protection, For WordPress

find below some discussion about it.

https://wordpress.org/support/article/htaccess/

The .htaccess is a distributed configuration file, and is how Apache handles configuration changes on a per-directory basis. WordPress uses this file to manipulate how Apache serves files from its root directory, and subdirectories thereof. Most notably, WP modifies this file to be able to handle pretty permalinks. This page may be used to restore a corrupted .htaccess file (e.g. a misbehaving plugin).

Code: Select all
Basic WP #Basic WP
# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]


# END WordPress

Code: Select all

<Files ~ "\.(php)$">
AuthUserFile /etc/httpd/htpasswd
AuthType Basic
AuthName "restricted"
Order Deny,Allow
Deny from all
Require valid-user
Satisfy any
</Files>


Typically WordPress only has the following which handled permalink processing and is not related to security:

Code: Select all
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>


# END WordPress

Recently I've found the WP htacess Control plugin that manages a lot of .htaccess for us
After tweaking it's settings it added the following options:

Code: Select all
# WPhtC: Disable ServerSignature on generated error pages
ServerSignature Off
# WPhtC: Disable directory browsing
Options All -Indexes
# WPhtC: Protect WP-config.php
<files wp-config.php>
order allow,deny
deny from all
</files>

# WPhtC: Protect .htaccess file
<files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
</files>


with additional some lines - there are a bit more options which are about performance instead of security:

Code: Select all
# WPhtC: Setting mod_gzip
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>


# WPhtC: Setting mod_deflate

Code: Select all
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent env=!dont-vary
</IfModule>


Beyond this one there are some plugins I haven't tried but that are focused on security and that interact with .htaccess - you might try them each just to see what they do to the .htaccess file:

Beyond that, if you want to know the (IMO) #1 expert resource on Apache security related to WordPress you can find it on AskApache.com; dude is hardcore! His blog won't solve your "too much information" problem but at least you can view it as an authoritative resource!

Here are some examples (though not all are directly WordPress related they all are applicable):

Advanced WordPress wp-config.php Tweaks
https://wordpress.org/plugins/wp-super-secure-and-fast-htaccess/


BulletProof Security https://wordpress.org/plugins/bulletproof-security/

WordPress Security Protection: Malware scanner, Firewall, Login Security, DB Backup, Anti-Spam & much more. View Security feature highlights below. View BulletProof Security feature details under the FAQ help section below. Secure your WordPress website even further by adding additional BulletProof Security Bonus Custom Code. See BulletProof Security Bonus Custom Code under the FAQ help section below. Effective, Reliable & Easy to use WordPress Security Plugin

Version:3.8
Last updated:3 weeks ago
Active installations:60,000+
WordPress Version:3.8 or higher
Tested up to:5.3.2

Description: WordPress Security Protection: Malware scanner, Firewall, Login Security, DB Backup, Anti-Spam & much more. View Security feature highlights below. View BulletProof Security feature details under the FAQ help section below. Secure your WordPress website even further by adding additional BulletProof Security Bonus Custom Code. See BulletProof Security Bonus Custom Code under the FAQ help section below. Effective, Reliable & Easy to use WordPress Security Plugin.

BULLETPROOF SECURITY INSTALLATION AND SETUP : SEE BULLETPROOF SECURITY FEATURE HIGHLIGHTS
One-Click Setup Wizard
Setup Wizard AutoFix (AutoWhitelist|AutoSetup|AutoCleanup)
MScan Malware Scanner
.htaccess Website Security Protection (Firewalls)
Hidden Plugin Folders|Files Cron (HPF)
Login Security & Monitoring
JTC-Lite (Limited version of BPS Pro JTC Anti-Spam|Anti-Hacker)
Idle Session Logout (ISL)
Auth Cookie Expiration (ACE)
DB Backup: Full|Partial DB Backups | Manual|Scheduled DB Backups | Email Zip Backups | Cron Delete Old Backups
DB Table Prefix Changer
Security Logging
HTTP Error Logging
FrontEnd|BackEnd Maintenance Mode
UI Theme Skin Changer (3 Theme Skins)
Extensive System Info
BULLETPROOF SECURITY PRO FEATURE HIGHLIGHTS

cf: https://wordpress.org/plugins/bulletproof-security/


Advanced WordPress wp-config.php Tweaks
https://www.askapache.com/wordpress/advanced-wp-config-php-tweaks/
wp-configThe bottom line for this article is that I want to make WordPress as fast, secure, and easy to install, run, and manage because I am using it more and more for client production sites, I will work for days in order to solve an issue so that I never have to spend time on that issue again. Time is money in this industry and that is ultimately (time) what there is to gain by tweaking WordPress.



Mod_Security .htaccess tricks
https://www.askapache.com/htaccess/modsecurity-htaccess-tricks/
.With over 70% of all attacks now carried out over the web application level, organizations need as much help as they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects, and prevents attacks before they reach web applications.
Target Audience:
Web Server Administrators
Web security Adminis
Security consultants and other ballers.
Web Developers


The idea behind .htaccess, if someone has got strangling files hanging behind from past upgrades or for zero-day attacks,
his whole system could be hacked. Also securing the wp-admin by another method will help against brute-force attacks.

So the idea of htaccess is a great idea: If it is just you editing the site you can limit access to the folder by ip doing something like

Code: Select all
<Files *>
Order deny,allow
Deny from All
Allow from 1.2.3.4
</Files>


To make it a bit more tolerable for dynamic IP systems; you should be able to allow from a subblock, so if you IP pool is always from 1.2.3.128 - 1.2.3.255, then you could do something like 1.2.3.128/25
Another Idea could be the following: require HTTPS, give a permissioned denied if they try it over http. But don't redirect them to the https. You can use a self-signed cert or one from CA Cert to get by without buying on

well i gathered some infos - since i need to have more of them to get a full overview on the topic.
if you have more information i would be glad... to hear from you

regards
by unleash_it
27. December 2019 00:36
 
Forum: Allerlei
Topic: What should the .htaccess file in wp-admin: .htaccess tricks
Replies: 0
Views: 292

Re: no login in phpmyadmin

thank you for replay.

now it doesnt enter at all it couldnt access with messege "access forbidden.new xampp security concept:access to the requested object is only availible from the local network".

this is inspite i tried from local host and 127.0.0.1

why it do that ?
best regards

Erez
by barzivb
26. December 2019 22:16
 
Forum: XAMPP for Windows
Topic: no login in phpmyadmin
Replies: 3
Views: 737

Re: risks on hosting wordpress - with the wrong configurati

hello dear Nemesis

- many thanks again for the quick reply - i am glad to hear from you.

Well i want to dig into the processes of the automatic-update: at the moment my server does not fullfill the needs that are mandantory to be met if one wants to run the automatic-updates:

Well in this posting i want to gather togehter all i can get - to understand these porcesses - in order to dive into this technique and to enlarge my understanding: the Wordpress site had been automatically updated to the latest version. I knew about the feature but I've always wondered exactly how it works. Therefore i gathered some information about hte update-process how it works and which credentials at serverside we need.

furthermore i have found some ideas about a shorter way to automatically update WordPress? here some infos on the updating WordPress plugins, there’s a prompt for the FTP login:

Connection Information:
To perform the requested action, WordPress needs to access your web server. Please enter the FTP credentials to proceed.
If we do not remember the credentials, we should contact our web host.
Hostname: host
FTP Username: user
FTP Password: pass
Connection Type: FTP or FTPS (SSL)

This will work fine, except if it’s host uses SFTP over SSH with Port 22.
Failed to connect to FTP Server host:21
It will attempt to always use port 21 as well.
This is the user’s permission problem.

step-1: First open wp-config.php file of your WordPress installation folder.
step-2: Copy below code and paste it at the end of the wp-config.php file.

define('FS_METHOD','direct');

we need to make sure ownership permissions are set to Apache so that WordPress can update and/or
install plugins without requiring FTP credentials. We can set permissions via SSH.

Single site hosting:
chown -R apache:apache /var/www/html
basically, it’s easy to set up wordpress-server to do the automated update:

- Permissions in the wordpress tree: 755 on directories, 644 on files.
- Ownership of files: The same user under which PHP is running

Once we have that, WP is able to update itself. By default, that means it will do minor update (e.g., 5.2.3 to 5.2.4),
but not major ones (5.2.x to 5.3.x), nor will it auto-update plugins. We can add constants to wp-config.php for core updating.
See https://wordpress.org/support/article/e ... re-updates.

For auto-updating themes and plugins, see https://www.wpbeginner.com/plugins/how- ... s-plugins/
Also a good read https://wordpress.org/support/article/e ... -constants

here i found a shorter way to automatically update WordPress?
cf: https://wordpress.stackexchange.com/que ... -wordpress

This is how we can start to update WordPress daily:

Code: Select all
cat <<-"CRON_DAILY" > /etc/cron.daily/nses_cron_daily
    for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp plugin update --all --allow-root; done
    for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp core update --allow-root; done
    for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp theme update --all --allow-root; done
    chown www-data:www-data /var/www/html/* -R
    find /var/www/html/* -type d -exec chmod 755 {} \;
    find /var/www/html/* -type f -exec chmod 644 {} \;
CRON_DAILY
chmod +x /etc/cron.daily/nses_cron_daily


I create the file with the heredocument, change permissions, and run daily.
Is there a shorter, pluginless way to update (less rows, hahaha)?
Update: I didn't change basically anything inside wp-config.php besides database credentials.

the Wordpress site had been automatically updated to the latest version. I knew about the feature but I've always wondered exactly how it works. PHP isn't a permanently-running process: it only runs when requested. So as far as I can tell, Wordpress can only update itself when someone loads a web page. But the update process is not instantaneous, so surely a user visiting the site would have a really slow page load. Is there a different trick they use for automatic updates? I've searched all over the place but haven't found any explanation.

some more into depth going details on the auto-update-process: the automatic update is pushed from wp.org. The update process still runs on our site, but in the background via wp-cron.
When a new minor update is released, the guys at WordPress start to roll out the update. The actual update process is started after our site checked wp.org for updates, an update is theoretically available, and our site is chosen by random to be updated. As every site checks with wp.org for new versions (usually twice dayily using wp-cron), the rolloutserver knows how many sites need an update. Then the rollout begins, starting slowly - 1 out of 128 sites gets updated automatically. This is being monitored, and if the successrate indicates no problems with the rollout, more of the sites get the automatic update (usually the next step would be 1 out of 64, and continuing to increase that way) until all automatic updates are delivered.
This enables the developers to stop the rollout if any problems occur, but the last update from 3.8 to 3.8.1 has had a 100% success rate. The sites selected by the 1 out of 128 is actually random. Well, not really, but if you want to know, it works like this: The Url of the site needing an update gets hashed using MD5. Using just the first three characters of this hash and converting it to base10, this results in 4096 possibilities. The update started for sites having a calculated number between 0 and 31 (4096 / 32 = 128).


cf: https://wordpress.stackexchange.com/que ... dates-work

and futhtermore i found more infos:

WordPress Automatic Updates :: There are four typologies of updates and WordPress automatic updates:

Core updates
Plugin updates
Theme updates
Translation files updates
Core updates are divided into three sub-typologies:

Core development (only available for development installations)
Minor core updates (maintenance and security) – enabled by default in stable installations
Major core updates
WordPress allows us to automate the update process for any of these typologies providing two wp-config.php constants and a good number of API filters.

Controlling Background Updates Through wp-config.php
WordPress provides a couple of wp-config.php constants that allow us to control auto-updates. Setting AUTOMATIC_UPDATER_DISABLED to true will disable any kind of automatic upgrade:

define( 'AUTOMATIC_UPDATER_DISABLED', true );
WP_AUTO_UPDATE_CORE allow us to control core updates (minor, major and development releases). This constant can be defined as follows:

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
In development installations WP_AUTO_UPDATE_CORE defaults to true. In stable installations it defaults to minor.

For the sake of completeness, I should mention an additional constant that can be defined to disable auto-updates. However, setting its value to true will disable any file edits, even themes and plugin installations and manual updates.

define( 'DISALLOW_FILE_MODS', true );
Instead, you may prefer to define the DISALLOW_FILE_EDITS constant, which would disable the file editor, but keeping safe the installation and update functionalities.

Related tutorial: wp-config.php File – An In-Depth View on How to Configure WordPress

Controlling Background Updates Through API Filters
Configuration constants provide a general way to enable or disable auto-updates. But WordPress provides a number of filters which grant a deeper control over any kind of updates.

Note: Filters should be used within plugins, and “must use plugins” are a good option for background updates. mu-plugins reside in a specific folder inside /wp-content and are automatically enabled by WordPress. These plugins do not appear in WordPress Plugins Screen, so they could not be accidentally disabled or removed by the site admins. For a deeper view, refer to the Codex documentation

First, returning true through the automatic_updater_disabled filter has the same effect as defining the AUTOMATIC_UPDATER_DISABLED constant to true in wp-config.php:

add_filter( 'automatic_updater_disabled', '__return_true' );
We can control any of the update typologies through the auto_update_$type filters which enable or disable updates depending on the value of $type ('core', 'plugin', 'theme' or 'translation').

So, we can automate all core updates by returning true through the auto_update_core filter:
Code: Select all
add_filter( 'auto_update_core', '__return_true' );
In the following example, we’re enabling automatic updates for themes, plugins and translations:

add_filter( 'auto_update_theme', '__return_true' );
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_translation', '__return_true' );
In the examples above we’ve ju st enabled auto-updates. But these filters give us a greater control over updates. In the following example we’re automating auto-updates for two specific plugins:

function cb_auto_update_plugins ( $update, $item ) {
   $plugins = array ( 'hello', 'akismet' );
   if ( in_array( $item->slug, $plugins ) ) {
      // update plugin
      return true;
   } else {
      // use default settings
      return $update;
   }
}
add_filter( 'auto_update_plugin', 'cb_auto_update_plugins', 10, 2 );
The callback function keeps two arguments:


$update: a boolean which sets wether to update or not;
$item: the update offer object. The function checks wether the item to update is in $plugins array, then returns true or false accordingly.

Last, we can make difference between development, minor and major updates, by returning true or false through the following filters:

Code: Select all
add_filter( 'allow_dev_auto_core_updates', '__return_false' );
add_filter( 'allow_minor_auto_core_updates', '__return_true' );
add_filter( 'allow_major_auto_core_updates', '__return_true' );
We know that occasionally an update can fail. In the worst case, the website can go down after an update failure. But luckily we can ask WordPress to notify us with an email after any update (or attempt).


suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp)

but generally speaking bout the Automatic WordPress Updates Using FTP/FTPS or SSH - in a more secure environment

Introduction When working with WordPress in a more secure environment where websites are not entirely world-writable, you will notice upgrades request FTP or FTPS credentials as the server itself does not typically have write access in properly-configured environments.

cf https://www.serverstack.com/blog/2013/0 ... or-ssh/20/

Entering these credentials for every upgrade can become quite tedious, and WordPress has implemented some constants you can define within wp-config.php to make upgrades automatic.
It should be noted here that you can also make upgrades automatic by setting the file ownership of all files within the WordPress directory to the same user/group under which the webserver is running. THIS IS HORRIBLE SECURITY PRACTICE! While storing your FTP credentials for a specific user can also be considered insecure in certain instances, it can be a very safe method to automate WordPress updates under the proper conditions. Some general considerations which can make stored credentials MUCH more secure include:

FTP:
1. Creating a separate user and restricting its access to only allow connections from localhost
2. Ensuring your FTP daemon is “chrooting” the user to their own directory only
3. Configuring your FTP daemon to listen only on localhost, thus preventing external connections
4. Using something more secure than FTP, such as SSH — Yes, we realize this one does not actually improve FTP security :)

SSH:
1. Creating a separate user (usually an alias with the same UID, different GID) and restricting access to only localhost for this specific user in sshd_config with the AllowHosts option
2. Creating some advanced SSH configuration such as chrooted SFTP-only users
3. Using public key authentication, which can be further secured by specifying a “from” address in the user’s authorized_keys file

There are several other ways one can make their FTP/FTPS or SSH setup more secure, but they are far beyond the scope of this post and can vary greatly in their application due to the hosting environment and several other factors. We are going to assume you’re already working with a secure setup for the purposes of this guide.




again Well in this posting i want to gather togehter all i can get - to understand these porcesses - in order to dive into this technique and to enlarge my understanding: the Wordpress site had been automatically updated to the latest version. I knew about the feature but I've always wondered exactly how it works. Therefore i gathered some information about hte update-process how it works and which credentials at serverside we need.
by unleash_it
25. December 2019 16:46
 
Forum: Allerlei
Topic: risks on hosting wordpress - with the wrong configuration
Replies: 5
Views: 400

risks on hosting wordpress - with the wrong configuration

hello and good day


risks on hosting wordpress - with the wrong configuration


When working with WordPress in a more secure environment where websites are not entirely world-writable,


you will notice upgrades request FTP or FTPS credentials as the server itself does not typically have write access in properly-configured environments. Entering these credentials for every upgrade can become quite tedious, and WordPress has implemented some constants you can define within wp-config.php to make upgrades automatic.

It should be noted here that you can also make upgrades automatic by setting the file ownership of all files within the WordPress directory to the same user/group under which the webserver is running. THIS IS HORRIBLE SECURITY PRACTICE!

While storing your FTP credentials for a specific user can also be considered insecure in certain instances, it can be a very safe method to automate WordPress updates under the proper conditions. Some general considerations which can make stored credentials MUCH more secure include:





end of cit: see more here https://www.serverstack.com/blog/2013/0 ... r-ssh/0020


well can you advice me

– what is needed to run the automated updates of plugins!?
– do i need to have suPHP enabled
– what else do i need to have?


by the way
– i need to have a overview on all necessary conditions and things…. – there a plugin suggests to get done all the things – i t is called infinitewp – but i guess that – to run this – i need to have the horrible server conditions too!?
by unleash_it
24. December 2019 10:26
 
Forum: Allerlei
Topic: risks on hosting wordpress - with the wrong configuration
Replies: 5
Views: 400

Can't open configs or logs with GUI, Kate can't be root

I'm new to XAMPP so please bear with me. I just installed XAMPP 7.3.12 and was unable to start httpd due to a default config issue. Upon trying to open the config I receive an error in console stating "Executing Kate with sudo is not possible due to unfixable security vulnerabilities." and nothing happens. I understand the risks of running X programs as root but the entire reason for setting up XAMPP was so I didn't have to work from console unless I wanted to (I operated a dedicated CentOS/cPanel box for many years and I don't want the hassle on this small hobby project). Also, I have notepadqq installed and would prefer it as default editor for development anyway. Can anyone provide some pointers on how to fix the sudo restriction and/or set notepadqq as default editor? Notepadqq is already set in KDE as default for plain text files and .log and .conf extensions but XAMPP continues to try to use Kate.

Also, from my research you should be able to open the files with Kate and be prompted for sudo password upon save so long as you don't try to launch Kate as sudo directly. If this is the case I just need the conf and log files loaded as normal user and I can elevate during save.
by Bestrafung
24. December 2019 10:19
 
Forum: XAMPP for Linux
Topic: Can't open configs or logs with GUI, Kate can't be root
Replies: 0
Views: 314

Re: Miniatur-Ansicht in Webserver

4ap4ch3 wrote:Serverfehler!
Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Der Server ist entweder überlastet oder ein Fehler in einem CGI-Skript ist aufgetreten. Infomieren sie den Webmaster.
Error 500
192.168.5.1


Genau. Hatte ich auch. Ich habe relativ brutal gelöscht:

1) in httpd.conf nur noch den einen DirectoryIndex zulassen:

Code: Select all
DirectoryIndex /_h5ai/public/index.php



2) In /_h5ai in .htaccess die Zeilen von "## SECURITY" bis "## COMPAT" löschen.

3) In /_h5ai/public die Datei .htaccess löschen.

Unter Linux muss ich noch viele Dateiberechtigungen ändern, ich vermute, das geht unter Windows auch einfach so.
by Nobbie
22. December 2019 18:49
 
Forum: Apache
Topic: Miniatur-Ansicht in Webserver
Replies: 27
Views: 1521

A WordPress automatic update-option: can this harm my websit

good day dear experts, 

 

well my Wordpress site is automatically updating itself when a new version of Wordpress is available. This is the good news:  I know that this automatic feature is available in Wordpress since sometimes back. But I have some questions about this:

the question is:  A WordPress automatic update-option: can this harm my website?

- Can this be risky in any case?
- do i need to have any server conditions that are risky?
- Does Wordpress have a way to recover our website if anything goes wrong?
- Does WordPress keep any backup when doing the update?

- and finally : Does it matter how we have installed Wordpress? (e.g plugins and security settings)!? - i am thinking bout all these questions for quite a long time. 


Let me express my woes bout the server-configuration - that we need to meet the needs for an automated update process. i guess that there is always some risk. But with the default of only doing minor core release we might be pretty safe. 
Also we should think of how while being some risk itself the update also protects all of us from other risks by e.g. fixing security issues. Automatic Background Updates have been introduced in WordPress  a long long time ago guess it was the version 3.7. 

In WordPress, there are four types of automatic background updates:

Core updates
Plugin updates
Theme updates
Translation file updates
Core Updates #Core Updates
Core updates are divided into three sub-typologies:

- Core development (only available for development installations)
- Minor core updates (maintenance and security) – enabled by default in stable installations
- Major core updates
- WordPress allows you to automate the update process for any of these typologies providing two wp-config.php constants and a good number of API filters.

Controlling Background Updates Through wp-config.php
WordPress provides a couple of wp-config.php constants that allow us to control auto-updates. Setting AUTOMATIC_UPDATER_DISABLED to true will disable any kind of automatic upgrade:

 
Code: Select all
define( 'AUTOMATIC_UPDATER_DISABLED', true );
WP_AUTO_UPDATE_CORE allow us to control core updates (minor, major and development releases). This constant can be defined as follows:

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
In development installations WP_AUTO_UPDATE_CORE defaults to true. In stable installations it defaults to minor.

 

For the sake of completeness, I should mention an additional constant that can be defined to disable auto-updates. However, setting its value to true will disable any file edits, even themes and plugin installations and manual updates.
Code: Select all
define( 'DISALLOW_FILE_MODS', true );



Instead, you may prefer to define the DISALLOW_FILE_EDITS constant, which would disable the file editor, but keeping safe the installation and update functionalities.

Related tutorial: wp-config.php File – An In-Depth View on How to Configure WordPress

Controlling Back

Codex for more info on how to do that: http://codex.wordpress.org/Configuring_ ... nd_Updates
Again you can find more info at the Codex: https://codex.wordpress.org/Updating_WordPress
regular backups anyway: https://codex.wordpress.org/WordPress_Backups


conclusio
: Automatic background updates were introduced in WordPress 3.7 in an effort to promote better security, and to streamline the update experience overall. 
By default, only minor releases – such as for maintenance and security purposes – and translation file updates are enabled on most sites. 


the question is: is there any risk in configuring the server so that tha auto updates are working!? 

by unleash_it
16. December 2019 17:51
 
Forum: Allerlei
Topic: A WordPress automatic update-option: can this harm my websit
Replies: 0
Views: 481

Re: Problem with makecert.bat

camaro73 wrote:i type in the letter and numbers but it doesnt show...

They will not show. Thats expected. It's a security feature.
by Altrea
29. November 2019 10:32
 
Forum: XAMPP for Windows
Topic: Problem with makecert.bat
Replies: 5
Views: 1072

Re: New xampp security concept: Access Forbidden Error 403

Hi,

- Is the machine xampp is installed on the same as from where you want to login to phpmyadmin?
- What is the contents of your phpmyadmin config.inc.php file?

best wishes,
Altrea
by Altrea
28. November 2019 06:47
 
Forum: XAMPP for Windows
Topic: New xampp security concept: Access Forbidden Error 403
Replies: 1
Views: 579

New xampp security concept: Access Forbidden Error 403

Hello,
I've installed XAMPP 7.3.3 on my Windows 2012.
I would like login me on PHPMYADMIN with a login and password, but how do this ?
When i try to login me, i've an error message : "New xampp security concept: Access Forbidden Error 403"

I've try to configure the HTTPD-XAMPP.conf, but this is not works
:( :( :(
is there anybody who knows a solution !??
by minou30
27. November 2019 21:34
 
Forum: XAMPP for Windows
Topic: New xampp security concept: Access Forbidden Error 403
Replies: 1
Views: 579

Re: Incorrect display of Polish diacritical marks in SHELL

belfer wrote:# Example MySQL config file for small systems.
#
# This is for a system with little memory (<= 64M) where MySQL is only used
# from time to time and it's important that the mysqld daemon
# doesn't use much resources.
#
# You can copy this file to
# C:/xampp/mysql/bin/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is C:/xampp/mysql/data) or
# ~/.my.cnf to set user-specific options.
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.

# The following options will be passed to all MySQL clients
[client]
# password = your_password
port=3306
socket="C:/xampp/mysql/mysql.sock"


# Here follows entries for some specific programs

# The MySQL server
default-character-set=utf8mb4
[mysqld]
port=3306
socket="C:/xampp/mysql/mysql.sock"
basedir="C:/xampp/mysql"
tmpdir="C:/xampp/tmp"
datadir="C:/xampp/mysql/data"
pid_file="mysql.pid"
# enable-named-pipe
key_buffer=16M
max_allowed_packet=1024M
sort_buffer_size=512K
net_buffer_length=8K
read_buffer_size=256K
read_rnd_buffer_size=512K
myisam_sort_buffer_size=8M
log_error="mysql_error.log"

interactive_timeout=9999
wait_timeout=9999

# Change here for bind listening
# bind-address="127.0.0.1"
# bind-address = ::1 # for ipv6

# Where do all the plugins live
plugin_dir="C:/xampp/mysql/lib/plugin/"

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
# commented in by lampp security
#skip-networking
#skip-federated

# Replication Master Server (default)
# binary logging is required for replication
# log-bin deactivated by default since XAMPP 1.4.11
#log-bin=mysql-bin

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id =1

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
# the syntax is:
#
# CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
# MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
# where you replace <host>, <user>, <password> by quoted strings and
# <port> by the master's port number (3306 by default).
#
# Example:
#
# CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
# MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
# start replication for the first time (even unsuccessfully, for example
# if you mistyped the password in master-password and the slave fails to
# connect), the slave will create a master.info file, and any later
# change in this file to the variables' values below will be ignored and
# overridden by the content of the master.info file, unless you shutdown
# the slave server, delete master.info and restart the slaver server.
# For that reason, you may want to leave the lines below untouched
# (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id = 2
#
# The replication master for this slave - required
#master-host = <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user = <username>
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password = <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port = <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin


# Point the following paths to different dedicated disks
#tmpdir = "C:/xampp/tmp"
#log-update = /path-to-dedicated-directory/hostname

# Uncomment the following if you are using BDB tables
#bdb_cache_size = 4M
#bdb_max_lock = 10000

# Comment the following if you are using InnoDB tables
#skip-innodb
innodb_data_home_dir="C:/xampp/mysql/data"
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_group_home_dir="C:/xampp/mysql/data"
#innodb_log_arch_dir = "C:/xampp/mysql/data"
## You can set .._buffer_pool_size up to 50 - 80 %
## of RAM but beware of setting memory usage too high
innodb_buffer_pool_size=16M
## Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size=1024M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout=50

## UTF 8 Settings
#init-connect=\'SET NAMES utf8\'
#collation_server=utf8_unicode_ci
#character_set_server=utf8
#skip-character-set-client-handshake
#character_sets-dir="C:/xampp/mysql/share/charsets"
sql_mode=NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTION
log_bin_trust_function_creators=1

character-set-server=utf8mb4
collation-server=utf8mb4_general_ci
[mysqldump]
max_allowed_packet=16M

[mysql]
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer=20M
sort_buffer_size=20M
read_buffer=2M
write_buffer=2M

[myisamchk]
key_buffer=20M
sort_buffer_size=20M
read_buffer=2M
write_buffer=2M

[mysqlhotcopy]

remove the red line, save and restart MariaDB
by Altrea
27. November 2019 14:29
 
Forum: XAMPP for Windows
Topic: Incorrect display of Polish diacritical marks in SHELL
Replies: 12
Views: 1063
Next

Return to advanced search