የsystemd አገልግሎት ፕሮክሲውን ያገኛል፣ CA ፋይሉን ግን አያገኝም

የተፈቀደውን CA ጥቅል ጭነዋል፣ ጥያቄውም በተርሚናል ይሠራል። አገልግሎቱ ግን የሰርተፊኬት ጭነት ስህተት እያሳየ ነው። የፕሮክሲ IP ከመቀየር በፊት ያ ሂደት ተመሳሳይ ፋይል መክፈት እንደሚችል ይፈትሹ።

አገልግሎት በሌላ Unix ተጠቃሚ ሊሠራ፣ ከተለየ ማውጫ ሊጀምር ወይም የተገደበ የፋይል ስርዓት ሊያይ ይችላል። ለእርስዎ መግቢያ የሚሠራ መንገድ ለእሱ በራሱ አይሠራም።

በፍጹም የፋይል መንገድ ይጀምሩ

በእውነተኛው ደንበኛ የተዋቀረውን መንገድ ይፈትሹ። በcurl ለምሳሌ --cacert የመድረሻውን CA ጥቅል ይመርጣል፤ HTTPS ፕሮክሲ የተለዩ የፕሮክሲ CA አማራጮች አሉት። ሌሎች ደንበኞች የራሳቸውን የቅንብር ቁልፎች ወይም የአካባቢ ተለዋዋጮች ይጠቀማሉ።

ፋይሉንና ወደ እሱ የሚወስዱትን ማውጫዎች ሁለቱንም ይመልከቱ፦

namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectory

እነዚህ የምርመራ ምሳሌዎች ናቸው እንጂ ፋይሉን ሁሉም ሰው የሚጽፍበት እንዲሆን መመሪያዎች አይደሉም። የማውጫ ማለፍ ፈቃድ እንደ የመጨረሻው ፋይል የንባብ ፈቃድ አስፈላጊ ነው።

ችግሩ ሙሉ በሙሉ ፈቃዶች ብቻ ላይሆን ይችላል

በProtectHome=yes፣ systemd መደበኛ የቤት ማውጫ ቦታዎችን ለአገልግሎቱ ተደራሽ አያደርግም። የሰርተፊኬት ፋይሉን ሁነታ መቀየር የስም ክልል ገደቡን አያስወግድም። የተዋቀረ ሥር ማውጫም በአገልግሎቱ ውስጥ ፍጹም መንገድ የሚጠቁመውን ሊቀይር ይችላል።

ለመተግበሪያው የተዘጋጀ በ/etc ሥር ያለ ማውጫ ያለ ተገቢ የአገልግሎት ቅንብር ቦታ ይጠቀሙ፣ አስፈላጊውን የንባብ መዳረሻ ብቻም ይስጡ። የደንበኛውን CA መንገድ ወደዚያ ያዘምኑ። የመጀመሪያው ቅጂ በግል የቤት ማውጫዎ ውስጥ ነበር ብለው ያልተያያዙ የፋይል ስርዓት ገደቦችን አያስወግዱ።

የመጀመሪያውን ጠቃሚ ስህተት ያንብቡ

«CA ፋይል መጫን አይቻልም» እና «የሰርተፊኬት ሰንሰለቱ አይታመንም» የተለያዩ ስህተቶች ናቸው። የመጀመሪያው ደንበኛው ምንም ከማረጋገጡ በፊት ሊከሰት ይችላል። ሁለተኛው ሊነበብ የሚችለው ጥቅል የተሳሳተ ባለሥልጣን እንዳለው ወይም ለተሳሳተ TLS ግንኙነት እየተጠቀመ መሆኑን ሊያሳይ ይችላል።

መዳረሻን ካስተካከሉ በኋላ ከአገልግሎቱ አውድ እንደገና ይፈትሹ። የተሳካ የተርሚናል ትእዛዝ ጠቃሚ ንጽጽር ነው፣ ግን አገልግሎቱ የትኞቹን ፋይሎች እንደሚያይ ወይም ደንበኛው የትኛውን የእምነት ቅንብር እንደሚጠቀም አያረጋግጥም።