Wordpress – automatyczna aktualizacja i FTP
Kilka wersji temu do Wordpress dodano funkcję automatycznej aktualizacji. Obecnie podczas pojawienia się nowej wersji systemu blogowego, jak i aktualizacji wtyczek pojawia się odpowiedni monit i możliwość aktualizacji przez WWW.
Dopóki blogi (m.in ten) stały na hostingu klikałem Aktualizuj i działało to auto-magicznie. Fajna sprawa, ułatwiająca życie, tym bardziej jeśli czuwa się nad X instancjami.
Ale po przenosinach na serwer dedykowany zamiast ekranu aktualizacji pokazało się okienko do wprowadzenia danych FTP celem zalogowania przez Wordpress i aktualizacji tą drogą.
Jak się domyślacie nie bylem szczęśliwy z tego powodu 
Nie chciałem tworzyć X kont FTP dla każdej instancji Wordpress albo tworzyć jednego super-konta FTP z dostępem do wszystkich stron.
Co było przyczyną prośby o dane FTP, zamiast szybkiej aktualizacji?
Wordpress podczas sprawdzania możliwości aktualizacji analizuje prawa dostępu do poszczególnych plików w ramach systemu blogowego. Jeśli serwer WWW ma odpowiednie prawa zapisu (niestety nie wystarczy tylko dla wp-content :/) robi aktualizacje automatycznie. W innym wypadku prosi o dane do logowanie.
Jeśli nie obawiacie się, że Wasz blog/strona może zniknąć, a chcecie mieć łatwiejsze życie nadajcie a+w dla wordpress/ 
Mateusz Kamiński
webit
28 paź, 2009
e tam, mam prawa 757 i nie dziala automatyczna aktualizacja
matipl
28 paź, 2009
@webit: hmm, ja po wydaniu chmod a+w -R strona.com/ zaczęło działać.
Może nie masz wszystkich plików z write ?
Retio
28 paź, 2009
@webit: chown -R www-data:www-data strona.com i działa
Antoni Jakubiak
29 paź, 2009
można też tak, (piszę z pamięci):
cd wordpress
chown -R www .
chgrp -R programisci .
chmod -R ug+rwX .
gdzie “www” to użytkownik na którym działa proces apacha, a “programisci” to grupa dla użytkowników którzy będę mieli prawo do edycji plików na serwerze. Aczkolwiek jest to brzydkie. Aby być bezpiecznym, po aktualizacji można zmienić właściciela plików, tak by nie był nim “www”.
Na shared hosting działa, gdyż w takich rozwiązaniach zwykle pliki nagrywane są z prawami zapisu dla serwera www.
matipl
29 paź, 2009
@Antoni: dodam tylko, że większość serwerów uruchamia się z prawami danego użytkownika (np. www-data), jak i grupy, te ‘programisci’ moze być mylące.
Brzydkie tak do końca nie jest, bo jak WP będzie miało dziurę to i tak ktoś nabrudzi w systemie
SongoQ
1 lis, 2009
Wystarczy wlasciciela i prawa do zapisu ustawic i dziala ok.
shadzik
2 lis, 2009
Matipl: jeśli PHP jest uruchamiane z prawami użytkownika to nawet jeśli WP ma dziure i ktoś się włamie na konto to nabrudzi tylko na danym koncie, a nie całym systemie. A wtedy wystarczą prawa 705 dla katalogów i 604 dla plików – aktualizacja oczywiście działa.
matipl
2 lis, 2009
@shadzik: + założenie że dana wersja PHP nie ma dziury
jak również dodatkowe oprogramowanie dostepne z poziomu PHP, a które można wykonać/wywołać.
Nie podawałem 70 i 60, bo często serwery WWW mają własnego usera, jak i grupę.
Pshemko
7 sty, 2010
Czy zamiast a+w -R jest jeszcze jakieś rozwiązanie żeby nie narażać strony na potencjalne zagrożenie z prawami?
matipl
7 sty, 2010
@Pshemko: trochę nie rozumiem pytania, poprzez danie praw zapisu wszystkim (a+w) narażasz się na zagrożenie
Ale jednocześnie masz możliwość edycji CSS, szablonów jak i aktualizację z poziomu WWW przez Wordpressa.
Pshemko
7 sty, 2010
Tak, to wiem, że (a+w) jest niebezpieczne. Jest?
Ale czy jest inny sposób na obejście tego problemu? Co miał na myśli Songo@ pisząc “Wystarczy wlasciciela i prawa do zapisu ustawic i dziala ok”?
Przyznam, że dopiero raczkuję na własnym vps-ie i łopatologia do mnie przemawia najbardziej
matipl
7 sty, 2010
@Pshemko: @Songo miał to samo na myśli co a+w z punktu widzenia serwera WWW.
Jeśli nie chcesz aby ktoś mógł modyfikować Twoje pliki przez WWW, to musisz ściągnąć “w”. Wgłąb się w tajniki Linuksa
Mimo wszystko nie nie uchroni Cię od częstszych błędów jak SQL Injection, XSS itp. To już wyłacznie zależy od konfiguracji maszyny, jak i jakości kodu, który jest wykonywany.
Zabranie dostępu do zapisu przez serwer WWW zapobiegnie przed usunięciem Twojej strony (w ogólności, bazę i tak ktoś może usunąć poprzez SQL Inj.) lub dodaniu kodu JS z jakimś malware.
Pshemko
7 sty, 2010
Zatem jak nadać prawa a+w serwerowi WWW?
matipl
7 sty, 2010
Nie chodzi o serwer, tylko pliki
Wchodzisz do katalogu gdzie masz Wordpressa jako superuser:
cd /sciezka_do_katalogu
chmod a+w -R ./
To wszystko, wtedy możesz poprzez WP edytować pliki szablonów, czy dokonywać aktualizacji.
Pshemko
7 sty, 2010
A nie wystarczą chmody 757 i 646? Co to znaczy ściągnąć “w”?
matipl
7 sty, 2010
Ze względów bezpieczeństwa nie powinno być zapisu (w), czyli powinno być ściągnięte.
Pisałem, zależy co rozumiesz pod:
Co do podawania w systemie numerycznym, zależy kto jest właścicielem pliku (musi być wtedy ten sam uzytkownik co serwer WWW).
Pshemko
7 sty, 2010
Czyli ze ściągniętym “w” nie będę mógł edytować plików, a a+w jest potencjalnie niebezpieczne. Innego wyjścia nie ma?
matipl
7 sty, 2010
Dokładnie, albo chcesz mieć prostotę aktualizacji i edycji, albo czuć się bardziej bezpiecznie…
Pshemko
7 sty, 2010
A jak to jest zrobione na zwykłym hostingu, że tam to działa bez problemu bez nadawania wyższych praw plikom?
matipl
7 sty, 2010
@Pshemko: na zwykłym hostingu po prostu wszystkie pliki można modyfikować z poziomu WWW
i po problemie