KNOLEDGEBASE · FANTASTICO
જુમલા દ્વારા સ્થાપિત જુમલા નમૂનાને એ. એફ. ટી. પી. દ્વારા સુધારી શકાતું નથી
છેલ્લું સુધારેલ 2020-04-05
આ એક વિશિષ્ટ સમસ્યા છે, સર્વર સુએક્ઝેક/પીએચપીએસયુએક્ઝેક ચલાવી રહ્યું નથી. ઉકેલ એ છે કે, મહેરબાની કરીને એફ. ટી. પી. દ્વારા ફાઇલો અપલોડ કરો અને પછી જુમલા ઘટક/નમૂનાનું જાતે સ્થાપન કરો.
આ સમજાવવામાં આવ્યું છે http://forum.joomla.org/index.php/topic,30796.0.htmlકારણોનો સારાંશ નીચે મુજબ છે અને અમે ટાંકીએ છીએ,
"પ્રથમ તો... તેનાથી કોઈ ફરક પડતો નથી કે તમારો વપરાશકર્તા અથવા HTTPd (અથવા કોઈ નહીં, અપાચે, જે પણ અપાચે વપરાશકર્તા છે) જુમલા કોર ફાઇલોની માલિકી ધરાવે છે. ફાઇલની માલિકી ફાઇલ બનાવવા પર નક્કી થાય છે. તે વપરાશકર્તા દ્વારા નક્કી કરવામાં આવે છે જે ઓપરેટિંગ સિસ્ટમ પ્રક્રિયાની માલિકી ધરાવે છે જે ફાઇલ સિસ્ટમમાં ફાઇલ બનાવે છે.
દૃશ્યઃ તમે વપરાશકર્તા તરીકે લૉગ ઇન થયા છો અને તમે તમારા મનપસંદ ટેક્સ્ટ એડિટર (ઉદાહરણ તરીકે vi) સાથે એક નવી ફાઇલ... something.txt બનાવો છો.
કારણ કે તમે લૉગ ઇન કરતી વખતે vi પ્રોગ્રામ ચલાવો છો (અમે ધારીશું કે આગળ જતાં વપરાશકર્તાનામ વપરાશકર્તા હશે). તેથી, વપરાશકર્તા એ vi પ્રક્રિયાની માલિકી ધરાવે છે જેણે ફાઇલસિસ્ટમ પર something.txt ફાઇલ બનાવી છે. આનો અર્થ એ છે કે ફાઇલ something.txt વપરાશકર્તાની માલિકીની હશે.
દૃશ્યઃ તમે એફ. ટી. પી. નો ઉપયોગ કરીને ફાઇલ... somethingElse.txt અપલોડ કરો છો.
તમે તમારા વપરાશકર્તા/પાસ કોમ્બોનો ઉપયોગ કરીને એ. એફ. ટી. પી. માં લૉગ ઇન કરેલ હોવાથી... તમે જે એ. એફ. ટી. પી. પ્રક્રિયા પર કામ કરી રહ્યા છો તેણે વપરાશકર્તાને યુઝરની માલિકીમાં ફેરવી દીધો છે. તેથી, જ્યારે ફાઇલ somethingElse.txt ફાઇલસિસ્ટમમાં અપલોડ કરવામાં આવે છે (બનાવવામાં આવે છે)... તે તે પ્રક્રિયાના માલિકની માલિકીની હશે જેણે તેને બનાવ્યું છે, યુઝર.
દૃશ્યાવલિ: તમે ફાઇલને php સ્ક્રિપ્ટ પર અપલોડ કરો છો જે તેને yetSomethingElse.txt તરીકે સાચવે છે (php સાથે સુએક્સેકનો ઉપયોગ ન કરીને).
ઠીક છે, અપાચે, સુરક્ષા કારણોસર, તેની "વિશેષ" વપરાશકર્તાની માલિકીની પ્રક્રિયાઓ ચલાવે છે... જેને ઘણીવાર કોઈ નામ આપવામાં આવતું નથી, અથવા અપાચે, અથવા HTTPd, અથવા અન્ય કોઈ સુંદર નામ કે જેને sysadmin તેને કોન્ફ ફાઇલમાં નામ આપે છે. તેથી આ કિસ્સામાં આપણે કહીશું કે અપાચે વપરાશકર્તાનું નામ HTTPd છે. તેથી, તમે તમારી ફાઇલને php સ્ક્રિપ્ટ પર અપલોડ કરો છો. Php અપાચે મોડ્યુલમાં ચાલી રહ્યું છે, જે અપાચે પ્રક્રિયામાં ચાલી રહ્યું છે..... અનુમાન કરો કે તેની માલિકી કોની છે?... તે સાચવે છે... વપરાશકર્તા HTTPd. આને કારણે... જ્યારે php કહે છે... મૂવ _ અપલોડ _ ફાઇલ () અને ફાઇલ yetSomethingElse.txt સાચવે છે... તે વપરાશકર્તા HTTPd સિવાય અન્ય કોઈની માલિકીની નહીં હોય. શું આ php માં બગ છે? શું તે અપાચેમાં બગ નથી? તે કોઈ બગ નથી?
સુએક્ઝેક એ એક એવી પ્રણાલી છે જેના દ્વારા અપાચે વપરાશકર્તાને બદલે છે અને વિનંતી કરવામાં આવી રહેલા ચોક્કસ વર્ચ્યુઅલ યજમાન માટે દસ્તાવેજ root ની માલિકી ધરાવતા વપરાશકર્તાના આધારે પ્રક્રિયા કરે છે. (તેમાં સુએક્ઝેકને પકડો?) આ એક ઉકેલ છે જે કેટલાક યજમાનો પ્રદાન કરે છે, અને અપાચે પ્રક્રિયાઓ દ્વારા બનાવેલી/સુધારેલી/વગેરે બધી ફાઇલોને યોગ્ય વપરાશકર્તાની માલિકીની મંજૂરી આપે છે.
તમે તમારી જાતને પૂછી રહ્યા હશો કે શા માટે અપાચે આ રીતે વર્તે છે.... હું તમને સૂચવીશ કે તે બધા પ્રશ્નો માટે નિર્દેશિત કરવામાં આવે http://www.apache.org
સારાંશમાં, આ સિસ્ટમમાં કોઈ બગ નથી, તે સિસ્ટમને કામ કરવા માટે બરાબર કેવી રીતે ડિઝાઇન કરવામાં આવી છે... શું તે તમારા જીવનને સરળ બનાવે છે? ના. પરંતુ તે સમજૂતી છે. ઘણા સંભવિત ઉકેલો છે... તેમાંથી એક એ. એફ. ટી. પી. ક્લાયન્ટ સ્તર છે જે મેં 1.1 માટે લખ્યું છે.
લુઇસ "
આ સમજાવવામાં આવ્યું છે http://forum.joomla.org/index.php/topic,30796.0.htmlકારણોનો સારાંશ નીચે મુજબ છે અને અમે ટાંકીએ છીએ,
"પ્રથમ તો... તેનાથી કોઈ ફરક પડતો નથી કે તમારો વપરાશકર્તા અથવા HTTPd (અથવા કોઈ નહીં, અપાચે, જે પણ અપાચે વપરાશકર્તા છે) જુમલા કોર ફાઇલોની માલિકી ધરાવે છે. ફાઇલની માલિકી ફાઇલ બનાવવા પર નક્કી થાય છે. તે વપરાશકર્તા દ્વારા નક્કી કરવામાં આવે છે જે ઓપરેટિંગ સિસ્ટમ પ્રક્રિયાની માલિકી ધરાવે છે જે ફાઇલ સિસ્ટમમાં ફાઇલ બનાવે છે.
દૃશ્યઃ તમે વપરાશકર્તા તરીકે લૉગ ઇન થયા છો અને તમે તમારા મનપસંદ ટેક્સ્ટ એડિટર (ઉદાહરણ તરીકે vi) સાથે એક નવી ફાઇલ... something.txt બનાવો છો.
કારણ કે તમે લૉગ ઇન કરતી વખતે vi પ્રોગ્રામ ચલાવો છો (અમે ધારીશું કે આગળ જતાં વપરાશકર્તાનામ વપરાશકર્તા હશે). તેથી, વપરાશકર્તા એ vi પ્રક્રિયાની માલિકી ધરાવે છે જેણે ફાઇલસિસ્ટમ પર something.txt ફાઇલ બનાવી છે. આનો અર્થ એ છે કે ફાઇલ something.txt વપરાશકર્તાની માલિકીની હશે.
દૃશ્યઃ તમે એફ. ટી. પી. નો ઉપયોગ કરીને ફાઇલ... somethingElse.txt અપલોડ કરો છો.
તમે તમારા વપરાશકર્તા/પાસ કોમ્બોનો ઉપયોગ કરીને એ. એફ. ટી. પી. માં લૉગ ઇન કરેલ હોવાથી... તમે જે એ. એફ. ટી. પી. પ્રક્રિયા પર કામ કરી રહ્યા છો તેણે વપરાશકર્તાને યુઝરની માલિકીમાં ફેરવી દીધો છે. તેથી, જ્યારે ફાઇલ somethingElse.txt ફાઇલસિસ્ટમમાં અપલોડ કરવામાં આવે છે (બનાવવામાં આવે છે)... તે તે પ્રક્રિયાના માલિકની માલિકીની હશે જેણે તેને બનાવ્યું છે, યુઝર.
દૃશ્યાવલિ: તમે ફાઇલને php સ્ક્રિપ્ટ પર અપલોડ કરો છો જે તેને yetSomethingElse.txt તરીકે સાચવે છે (php સાથે સુએક્સેકનો ઉપયોગ ન કરીને).
ઠીક છે, અપાચે, સુરક્ષા કારણોસર, તેની "વિશેષ" વપરાશકર્તાની માલિકીની પ્રક્રિયાઓ ચલાવે છે... જેને ઘણીવાર કોઈ નામ આપવામાં આવતું નથી, અથવા અપાચે, અથવા HTTPd, અથવા અન્ય કોઈ સુંદર નામ કે જેને sysadmin તેને કોન્ફ ફાઇલમાં નામ આપે છે. તેથી આ કિસ્સામાં આપણે કહીશું કે અપાચે વપરાશકર્તાનું નામ HTTPd છે. તેથી, તમે તમારી ફાઇલને php સ્ક્રિપ્ટ પર અપલોડ કરો છો. Php અપાચે મોડ્યુલમાં ચાલી રહ્યું છે, જે અપાચે પ્રક્રિયામાં ચાલી રહ્યું છે..... અનુમાન કરો કે તેની માલિકી કોની છે?... તે સાચવે છે... વપરાશકર્તા HTTPd. આને કારણે... જ્યારે php કહે છે... મૂવ _ અપલોડ _ ફાઇલ () અને ફાઇલ yetSomethingElse.txt સાચવે છે... તે વપરાશકર્તા HTTPd સિવાય અન્ય કોઈની માલિકીની નહીં હોય. શું આ php માં બગ છે? શું તે અપાચેમાં બગ નથી? તે કોઈ બગ નથી?
સુએક્ઝેક એ એક એવી પ્રણાલી છે જેના દ્વારા અપાચે વપરાશકર્તાને બદલે છે અને વિનંતી કરવામાં આવી રહેલા ચોક્કસ વર્ચ્યુઅલ યજમાન માટે દસ્તાવેજ root ની માલિકી ધરાવતા વપરાશકર્તાના આધારે પ્રક્રિયા કરે છે. (તેમાં સુએક્ઝેકને પકડો?) આ એક ઉકેલ છે જે કેટલાક યજમાનો પ્રદાન કરે છે, અને અપાચે પ્રક્રિયાઓ દ્વારા બનાવેલી/સુધારેલી/વગેરે બધી ફાઇલોને યોગ્ય વપરાશકર્તાની માલિકીની મંજૂરી આપે છે.
તમે તમારી જાતને પૂછી રહ્યા હશો કે શા માટે અપાચે આ રીતે વર્તે છે.... હું તમને સૂચવીશ કે તે બધા પ્રશ્નો માટે નિર્દેશિત કરવામાં આવે http://www.apache.org
સારાંશમાં, આ સિસ્ટમમાં કોઈ બગ નથી, તે સિસ્ટમને કામ કરવા માટે બરાબર કેવી રીતે ડિઝાઇન કરવામાં આવી છે... શું તે તમારા જીવનને સરળ બનાવે છે? ના. પરંતુ તે સમજૂતી છે. ઘણા સંભવિત ઉકેલો છે... તેમાંથી એક એ. એફ. ટી. પી. ક્લાયન્ટ સ્તર છે જે મેં 1.1 માટે લખ્યું છે.
લુઇસ "
અમને જણાવો કે શું રહેવાનું છે.
A short conversation with an engineer. No quote-bot, no callback queue.