Witam
czy jest szansa że ktoś wytłumaczy mi jak krok po kroku zainstalować mysql noinstall? mam juz apache i php wszystko działa tylko do szczęścia jeszcze potrzebuję mysql.
pytacie po co się pchasz w pakiet noinstall jak nie masz o tym pojęcia! przyczyna jest prosta wszystkie .msi nie działają przy wersji 32bitowej wywala mi że dane konfiguracji dla tego produktu są uszkodzone a w wersji 64 w połowie instalacji jest komunikat że nie może usunąć poprzedniej wersji
więc myślę że noinstall jest moim jedynym rozwiązaniem(?)

Potrzebujesz serwer www na W7? Zainstaluj sobie XAMPP'a / WAMPP'a

miałem już xampaa i krasnala we wszystkich brakowało mi albo obsługi smtp albo ograniczone funckje a teraz chciałbym mieć serwer który składa się z tych narzędzi które chce więc te gotowce raczej odpadają ale dzięki za odpowiedź

Przecież jakiś prosty serwer SMTP możesz doinstalować już do gotowej paczki, poszukaj na forum, bo było wiele razy. [;

erix, ok ale zrobie to juz jako ostateczność, zostane przy tym co narazie mi działa i mam nadzieje że ktos pomoze z mysql

Po jaką cholerę na windzie ćwiczyć z serwerami Takie rzeczy to domena administratorów serwerów i systemów unixowych, serwer na windzie stawia się po to, by mieć szybko i łatwo warsztat pracy a do tego wystarczy XAMPP aż nadto.

- krasnal to rozumiem, ale czego w xamppie Ci brakowało? Przecież tam jest wszystko, nawet Zend Framework.

Nawet jak uporasz się z ręcznym dorzuceniem mySql to jak w banku za chwilę przylecisz z kolejnym problemem (a to jakiś dodatek, a to konfiguracja), dlatego stanowczo odradzam bawienie się na windowsie w takie rzeczy.

ok bawie sie juz na xamppie rzeczywiscie ma wiecej funkcji od tych ktore widac w panelu admina dzięki wszystkim za odpowiedzi i mysle że temat można usunąć bo nic nowego na forum nie wniósł

bzdura na resorach do kwadratu
kto ci takich głupot do głowy na wkładał? masz wersje serwerowe Windowsów i w pewnych kategoriach Linuxy jakby to powiedzieć chowają się przy tym -> AD, Exchange, aplikacje webowe, podkrelam słowo aplikacje a nie skrypty



konfiguracja Apache, MySQL i PHP jest praktycznie taka sama pod Windows jak i Linux, jeżeli ktoś nie umie pod jednym, pod drugim też nie zrobi

jeżeli chodzi o samo zainstalowanie usługi mysql to trzeba wydać magiczne polecenie:
mysqld.exe --install
NET START MySQL

dobra rada: douczyć się obsługiwać cmd.exe to nie wstyd i obciach, bo pożyteczna umiejętność przydatna w takich jak opisywana sytuacjach

Prachwal, ale z tego co widzę, to on che tego mysql w wersji noinstall, a więc zapewne instalowanie go jako usługi nie wchodzi w grę. I odpowiem mu, że się da właśnie w XAMPP. Sam ostatnio zrobiłem sobie full portable XAMPP odpalany jednym batem To tak naprawdę wywołanie jego CLI by uruchomić serwery odpowiednie... Mi był potrzebny tylko apache, mysql i dodatkowo od razu machałem portable firefoxa na określony adres Tutaj tylko pokażę co zrobiłem by obie pierwsze odpalić.

[DOS] pobierz, plaintext 
@ECHO OFF & SETLOCAL
PUSHD %~dp0
 
ECHO Now we start Apache
xampp_cli.exe start apache
ECHO Now we start MySQL
xampp_cli.exe start mysql
POPD
PAUSE
[DOS] pobierz, plaintext 

jeżei tak to pewnie chodzi o wersję portable
http://wiki.uniformserver.com/index.php/Mi...5.0.67_Portable

Poza tym strzelasz jedną głupotę... Od kiedy AD i Exchange mają być gorzej obsługiwane przez Windowsa, skoro to dla i przez niego były wprowadzone? AD zostało stworzone przez Microsoft jako implementacja własna LDAP, a LDAP Linux bez problemu obsługuje Tak więc to tak jakbym Ci kazał na Windowsie implementować coś natywnego dla Linuxa i potem marudził, że źle działają, a na Linuxie 100x lepiej Exchange to microsoftowy twór porównywalny z Lotusem. Ale bez jaj... Podaj przykłady nie microsoftowych usług, w których obsłudze celuje Windows Ta firma od początku tworzyła własne implementacje czego się da, które wielokrotnie nie są z niczym kompatybilne. Potem muszą się inni przystosowywać do tego co M$ stworzył bo koszty migracji byłyby ogromne, bądź sama migracja niemożliwa z racji zastosowania przez tę firmę pewnych rozwiązań, które są częścią systemu i ich emulacja byłaby po prostu niewygodna lub byłaby głupotą. Stąd między innymi takie problemy z AD na Linuxie, który ma zupełnie inną architekturę. Nawet durne udostępnianie plików pomiędzy maszynami na obu systemach wymaga się trochę nawkurzania by obie maszyny widziały to samo. Bo albo windows nie widzi linuxowych, albo vice versa, albo są problemy z uprawnieniami.

Aha... i bym nie dodał... Nie chodzi mi tutaj o to, że sobie gdzieś w sieci stoi jeden serwerek samby gdzie ludzie robią co chcą, ale fakt, że jedna maszyna to Linux ze swoją Sambą, a druga to Windows z jego własnym udostępnianiem plików i trzeba to po sieci dograć by nie było problemów oraz bez żadnego pośrednika. Kto nie konfigurował w jednej sieci maszyn na różnych osach stojących ten nie wie jakie to upierdliwe.

pod linuxa nie ma porównywalnych produktów, takich że wszystko działa w takim zakresie jak AD lub Exchange w porównywalnej cenie. Zakładam że admin nie pracuje za miskę ryżu.
Dodaj do tego pełną integrację AD z resztą, przez co w szybki i łatwy sposób całym interesem się zarządza
Z migracji widziałem tylko migrację do AD z Novel-a, i prawdę powiedziawszy nikt za Novelem nie płakał

Tylko że AD i Exchange możesz użyć TYLKO jeśli wszystkie maszyny w sieci pracują na windowsie lub w jakiejś szczątkowej formie i prymitywny sposób go obsługują(mieszanie usług samby + kerberosa, bo od win2000 "łaskawie" jego obsługa jest możliwa). W sieciach gdzie tego warunku nie można spełnić możesz te rozwiązania wyrzucić do kosza. Kilka maszyn na Mac, kilka na Linuxie, kilka na windzie i AD może mnie pocałować tam gdzie światło nie dochodzi Jest to rozwiązanie po prostu tylko tam gdzie zakłada się korzystanie z rozwiązań microsoftowych. W każdych innych to po prostu kaleka, niewypał. To samo można osiągnąć, gdy w sieci są same Maci lub same Linuxy. One mają własne narzędzia do tego. To, że zazwyczaj na jakimś kompie w sieci windows jest, wymusza dopasowanie się do tego "ułoma", który nic poza swoimi usługami nie zrozumie Tak wygląda sprawa z tymi rozwiązaniami. A to że AD tak fajnie się zarządza wynika z jego dużej integracji z systemem. To coś co na innych systemach jest po prostu nieakceptowalne. Za taką jednak wygodę się płaci obniżonym bezpieczeństwem choćby. Po prostu coś za coś. Albo wygoda, albo bezpieczeństwo. Chcesz mieć w jednym więcej to w drugim masz mniej. Tych dwóch rzeczy nie da się pogodzić. Microsoft idzie po tej pierwszej ścieżce i stąd tyle poważnych problemów. Gdy zaczyna iść w stronę bezpieczeństwa to się userzy burzą ( choćby sprawa UAC ) i musi się firma ugiąć oraz obniżyć znów bezpieczeństwo, by najsłabsze ogniwo w łańcuchu - człowiek - nie było zasypywane komunikatami. Linux idzie z kompletnie przeciwnej strony. Zaczął od maksymalnie bezpiecznej strony i teraz drogą pewnych uproszczeń, poluźnienia polityki bezpieczeństwa, staje się pewną alternatywą dla ludzi, którzy potrafią tylko klikać. Wiele rzeczy bowiem jest już zaopatrzonych w proste, wyklikiwalne konfiguratory. Skomplikowane nadal wymagają grzebania, ale postawić desktop komuś pokroju obecnego nastolatka to w zasadzie nie problem. Będzie mial problem z pewnymi rzeczami i będzie się musiał przestawić trochę, ale jest to możliwe.

No ale mimo wszystko, dyskutujemy raczej o skryptach. A IIS, z tego co mi wiadomo, nie posiada niczego, co by w łatwy sposób pozwoliło na dynamiczną zmianę w konfiguracji, choćby na stosowanie rewrite'a bez konieczności grzebania w konsoli zarządzania.

I tutaj, niestety, developer jest skazany na korzystanie z Apache. Dlaczego niestety? Bo port Apache na Windows jest niedorobiony i często niestabilny...

http://ruslany.net/tag/urlrewrite/
zmiana w pliku rewritemaps.config = zmiana w pliku .htaccess
IIS, serwer jak każdy inny, jest tak samo kosmiczny jeżeli chodzi o konfigurację jak np. lighttp. cała konfiguracja od wersji 6 IIS-a jest w plikach XML



PHP można odpalić praktycznie na dowolnym serwerze, i nie ma przymusu korzystania z Apache, może być to dowolny serwer z dostępnych w instrukcji instalacji PHP. Różnica jest żadna z punktu widzenia dewelopera. grunt to żeby umieć ustawić to co jest w aktualnej chwili potrzebne a z tym bywa rożnie dla dowolnego serwera WWW

co Apache pod win32 ma niedorobionego? jedyna "niedoróbka" o której słyszałem to mniejsza wydajność - bez znaczenia z punktu widzenia dewelopingu

No tak, ale występuje nadal niekompatybilność formatów. Tu dobrze zrobił Litespeed - skorzystał z najpopularniejszego formatu zapisu konfiguracji i migracja Apache-Litespeed jest praktycznie przezroczysta. Ale dobrze wiedzieć.


Jasne. Tylko że większość hostingów oferujących PHP działa na czymś apache-podobnym, więc co mi po innych? Maszyna developerska powinna być jak najbardziej zbliżona środowiskowo do serwera produkcyjnego. Czyli - chcąc nie chcąc - musi być Apache.


Na forum sporo osób miało problemy pod Windows, to raz. Dwa - czasem cały serwer jest mrożony (nie przyjmuje żadnych żądań niezależnie od kopii systemu; na kilku miałem podobnie) i pomaga tylko jego zabicie. Trzy - z podobnych powodów flooduje czasem procesor.

Na Windows - jeśli chodzi o stabilność - nadaje się tylko IIS i kilka pomniejszych projektów (całkiem przyjemnie pracował Abyss, który pozwalał na łączenie z interpreterami nawet za pośrednictwem named pipes, co mnie dość mocno zaskoczyło ).

napisałem aplikację w PHP, działa pod linuxem, autentykacja jest dla userów z AD - bardzo wygodne, nie trzeba bawić się w zakładanie tabelek z userami, hasłami itp, itd, przynależność do grup można sprawdzić bezpośrednio w kontrolerze domeny za pomocą sprytnego zapytania LDAP-owego - działa jak złoto

co do windows-a starszego niż 2000 - nie wiem czy gdzieś coś uświadczysz, trzeba by się naprawdę postarać

co do ułomności AD i mechanizmów zarządzania stacjami roboczymi - jakie ten mechanizm ma ułomności z punktu widzenia osoby zarządzającej - uważam że niema żadnej. Stacje robocze można konfigurować wedle uznania i potrzeb, grupować w logiczne jednostki o tych samych ustawieniach itp, itd

jakie konkretnie są zagrożenia bezpieczeństwa w środowisku domenowym? jeżeli admin chce to twoja rola na stacji roboczej będzie ograniczona do szarego usera który nie może nic, np nie uruchomi programów z poza listy. mechanizm UAC jest dedykowany do maszyn domowych, gdzie user z defaultu ma szersze uprawnienia, co by gierkę mógł sobie np. zainstalować




co takiego daje Apache że musisz na nim pracować z punktu widzenia PHP? załóżmy że u hostingodawcy PHP działa jako fastCGI



w życiu nie miałem tego typu problemów, może nie korzystałem z jakiegoś archaicznego krasnala/xampa gdzie aktualność oprogramowania czasem pozostawia wiele do życzenia

Ja nie mówię teraz o PHP. Interpreter może być przez CGI/FastCGI/SAPI/czy nawet jakiegoś niewolnika przepisującego pakiety. Co takiego daje? Przeciążanie konfiguracji z poziomu pliku, bez grzebania w globalnej konfiguracji. Gdyby inne httpd miały coś na kształt htaccess, tylko kompatybilnego, nie siedziałbym ani chwili dłużej przy apache.


No ja staram się w miarę na bieżąco łatać i httpd nie jest paczkowany, tylko instalowany osobno.

Zauważ, że napisałem, iż AD jest implementacją LDAP. Dopóki Linux nie korzysta z czegoś co jest stricte wymysłem AD, chodzi w porządku, bo Linux bez problemu radzi sobie z LDAP. Uwaga o niekompatybilności wiąże się więc nie z samym AD ale różnicach jego implementacji w stosunku do LDAP z którego się wywodzi. To tak jak z dialektami sql. Jest standard i jest MSSQL MySQL czy OracleSQL. Niby wszystkie podobne, ale diabeł tkwi w szczegółach i jedne mają coś czego nie ma inny (taka choćby pivot_table w MSSQL to już kombinowanie na MySQL).

Postarać? Może. Widziałem działające jeszcze na NT 4.0 gdzieniegdzie.

Od strony zarządzania AD jest bardzo fajny do tego stopnia, że aż przesadnego. Trzeba bowiem uważać by nie przesadzić z tą zarządzalnością bo się rozdrobi całość za bardzo. Potem wynikać mogą (ale nie muszą) z tego problemy na poziomie łączności stacji w sieci.

Co do zagrożeń w domenie to paradoksalnie ten ścisły reżim i określanie roli stacji potrafi spowodować konflikty, gdy się tą zarządzalnością za bardzo nadzorca zachłyśnie. Potrafią się pojawić konfiguracje wzajemnie wykluczające pewne drobne elementy i trudno potem dojść gdzie tkwi błąd. To samo ogólnie tyczy bardzo rozbudowanych aplikacji. Im masz więcej możliwości do skonfigurowania, tym prościej popełnić drobny błąd. Dlatego też trzeba mieć jakąś wiedzę zabierając do tego. Nie twierdzę, że AD jest najgorszym rozwiązaniem, ale w środowisku wielosystemowym wymaga także bardzo dużej wiedzy wbrew temu co mówisz o prostocie i łatwym zarządzaniu.

Przykład UAC miał być tylko wskazaniem niemożliwości pogodzenia bezpieczeństwa i prostoty obsługi. Zawsze trzeba zrezygnować z jednego na rzecz drugiego. W AD/LDAP też czasem trzeba tak zrobić.