OpenVPN-ის შემთხვევითი არჩევანი systemd-ში: რატომ მარცხდება ExecStart

ორმოცი .ovpn ფაილი ერთი ქვეყნისთვის მოდის პროვაიდერისგან და გეგმა ცხადი ჩანს: დააკოპირეთ შემთხვევითი ერთი თავის ადგილას, შემდეგ გაუშვით გვირაბი. როცა ეს ExecStart-ის შიგნით მილსადენად იწერება, ის გეგმა ჩატვირთვისას კვდება სტატუსის კოდით, რომელიც არაფერს ხსნის. ერთეულის ფაილი სკრიპტი არ არის და შესწორება ან shell-ის ცხადად შემოყვანაა, ან ფაილების არჩევის სრულად შეწყვეტა.

სიმპტომი: ერთეული, რომელიც ირთვება და მაშინვე კვდება

სტატუსი აჩვენებს, რომ სერვისი წამის ნაწილში ჩავარდა, ხოლო ჟურნალის ხაზი ასახელებს ბრძანებას, რომელსაც არც ერთი shell არასდროს მიიღებდა. გვირაბზე არაფერი ჩნდება, რადგან გვირაბი არასდროს დაიწყო.

ჟურნალიდან ზუსტი ბრძანების ხაზის წაკითხვა ამის დადასტურების ყველაზე სწრაფი გზაა. systemd იმეორებს იმას, რაც შეასრულა, და სტრიქონი მილსადენის სიმბოლოებს ლიტერალურ არგუმენტებად აჩვენებს და არა ოპერატორებად.

რატომ ვერ უშვებს ExecStart მილსადენს

systemd თავად ყოფს ბრძანების ხაზს, იყენებს საკუთარ ბრჭყალებსა და ცვლადების ჩანაცვლებას და შემდეგ შედეგს პირდაპირ ასრულებს. მილები, გადამისამართება, shell-ის გლობ გაფართოება და ბრძანების ჩანაცვლება უბრალოდ ამ გრამატიკის ნაწილი არ არის. ეს დიზაინის არჩევანია და არა გამოტოვება: ერთეული დეკლარაციულად ამბობს, რა უნდა გაეშვას, და shell-ის ლოგიკა ეკუთვნის სკრიპტს, რომელსაც ერთეული იძახებს. ორივე შესწორება აქედან გამომდინარეობს და არც ერთი მათგანი არ მოითხოვს ერთეულისთვის მეტი უფლების მიცემას.

ეს ასევე ხსნის შემცდომელ გასვლის კოდს. პირველი არგუმენტი ბინარულ ფაილად განიხილება, ამიტომ არასწორი ხაზი იშლება თქვენი ლოგიკის რომელიმე ნაწილის გაშვებამდე.

გააკეთეთ არჩევანი ExecStartPre-ში

პირდაპირი შესწორება მოსამზადებელი ნაბიჯია, რომელიც ცხადად იძახებს shell-ს და არჩევანსა და გაშვებას ერთსა და იმავე ერთეულში ინახავს, რათა ერთში ჩავარდნამ მეორე მარტოს არ დატოვოს მომუშავე.

[Service]
Type=notify
ExecStartPre=/bin/bash -c "ls /etc/openvpn/profiles/au* | shuf -n 1 | xargs -r -I{} cp -f {} /etc/openvpn/%i.conf"
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/%i.conf

სამი დეტალი წყვეტს, გაუძლებს თუ არა ეს რეალურ მანქანასთან შეხვედრას. სახელდება პირველი ხაფანგია: systemd %i-ს ერთეულის ანალიზისას ცვლის, ბევრად ადრე, ვიდრე bash გაეშვება, ამიტომ განმსაზღვრელი ერთჯერადი ბრჭყალების გარეთ უნდა იდგეს. xargs -r ხელს უშლის cp-ს არგუმენტის გარეშე გაშვებას, როცა გლობი არაფერს ემთხვევა. ხოლო ჩავარდნილი მოსამზადებელი ნაბიჯი აჩერებს ერთეულს და ეს სწორი შედეგია: გუშინდელი კონფიგურაციით დაწყება უარესია, ვიდრე საერთოდ არდაწყება. შემთხვევითი არჩევანი, რომელიც ყოველთვის ერთსა და იმავე ფაილს იღებს, ჩვეულებრივ ცუდი იღბალი არ არის. შეამოწმეთ, გადაფარავს თუ არა კოპირებულ ფაილს პაკეტის განახლება, ან ემთხვევა თუ არა გლობი მხოლოდ ერთ მოძველებულ ჩანაწერს.

ან მიეცით OpenVPN-ს საბოლოო წერტილის არჩევა

OpenVPN უკვე შეუძლია ერთ პროფილში რამდენიმე საბოლოო წერტილის შენახვა და მათ შორის შემთხვევითი არჩევა, რაც shell-ს, ასლს და ჩაწერის უფლებას მთლიანად აშორებს ჩატვირთვის გზას.

client
remote-random
<connection>
remote au1.example.net 1194 udp
</connection>
<connection>
remote au2.example.net 1194 udp
</connection>

ეს ფორმა სერვერის არჩევანს პროვაიდერის დაწერილ ფაილში ინახავს, ამიტომ ფაილების გადარქმევადი როტაცია ერთეულს არ ამტვრევს. ის ასევე კანდიდატების სიას შემოწმებადს ხდის, რაც კატალოგზე გლობს არასდროს აქვს. შერევა მაინც იმსახურებს თავის ადგილს, როცა პროფილები ერთ საბოლოო წერტილზე მეტით განსხვავდება: სხვადასხვა სერტიფიკატი, სხვადასხვა მარშრუტიზაციის დირექტივა, სხვადასხვა შიფრის პოლიტიკა. ამ შემთხვევაში არჩევანი მთლიან კონფიგურაციებს შორისაა და shell-ის ნაბიჯი ამის გამოხატვის პატიოსანი გზაა.

წაიკითხეთ უკან ეგზემპლარი და ფაილი, რომელიც მან გამოიყენა

დარწმუნდით, რომელი ერთეული მუშაობს სინამდვილეში, სანამ მის შიგთავსს გამართავთ. შეფუთული მეტა-სერვისი და შაბლონი ინფრასტრუქტურაა; თქვენი ფაილების შესაბამისი ერთეულები სწორედ ის ეგზემპლარებია, რომლებიც მათ სახელზეა დარქმეული.

systemctl list-units 'openvpn*'
systemctl cat [email protected]
journalctl -u openvpn@au -n 30 --no-pager

ეგზემპლარი, რომლის ჩართვა არავის ახსოვს, ჩვეულებრივ პაკეტის კატალოგში მოხეტიალე კონფიგურაციის ფაილამდე მიდის. გამორთეთ სწორედ ის დასახელებული ეგზემპლარი და არა შაბლონი, თორემ შემდეგი პაკეტის განახლება მას დააბრუნებს. ცვლილების შემდეგ გაუშვით ერთეული და წაიკითხეთ ბრძანების ხაზი, რომელსაც ჟურნალი იტყობინება, შემდეგ დაადასტურეთ კონფიგურაციის გზა, რომელიც მან ნამდვილად გახსნა. ეს ერთი შემოწმება გამოყოფს მომუშავე შემთხვევით არჩევანს იმ სერვისისგან, რომელიც ჩუმად ხელახლა იყენებს გასული თვის ფაილს.