ავტომატურად შედით Lync კონფერენციაზე Linux

ჰეი ჰაბრ!

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

Entry

ყველაფერი მაშინ დაიწყო, როდესაც გარკვეული დროის წინ სამსახურის კომპიუტერში რაღაც გადმოვწერე Linux მინანქარი. ბევრმა ალბათ იცის, რომ Pidgin Sipe დანამატით Microsoft Lync-ის (ახლა Skype for business-ის სახელით ცნობილი) ძალიან კარგი ჩანაცვლებაა. Linux სისტემები. ჩემი სამუშაოს ბუნებიდან გამომდინარე, ხშირად მიწევს SIP კონფერენციებში მონაწილეობა და როდესაც Windows-ის მომხმარებელი ვიყავი, კონფერენციებში მონაწილეობის მიღება მარტივი იყო: ელექტრონული ფოსტით ვიღებთ მოწვევას, ვაწკაპუნებთ შეერთების ბმულზე და უკვე შევდივართ.

ბნელ მხარეს გადასვლისას Linux საქმე ცოტა უფრო გართულდა: რა თქმა უნდა, Pidgin-ში შეგიძლიათ კონფერენციებში მონაწილეობის მიღება, მაგრამ თქვენ უნდა შეხვიდეთ თქვენი SIP ანგარიშის პარამეტრებში, აირჩიოთ მენიუდან „კონფერენციაში მონაწილეობის მიღება“ და შემდეგ ჩასვათ კონფერენციის ბმული ან შეიყვანოთ ორგანიზატორის სახელი და conf ID გახსნილ ფანჯარაში. გარკვეული დროის შემდეგ, დავიწყე ფიქრი: „ნუთუ არ არსებობს ამის გამარტივების გზა?“ დიახ, შეიძლება იკითხოთ, რატომ ჯანდაბაში გჭირდებათ ეს? თქვენ Windows-ს უნდა იყენებდეთ და არ ღელავდეთ.

ნაბიჯი 1: კვლევა

„თუ შენს თავში რაღაც ახირება გაგიჩნდება, მას ფსონის საშუალებით ვერ დაამარცხებ“, - თქვა ნეკრასოვმა თავის ნაშრომში „ვინ კარგად ცხოვრობს რუსეთში“.

ასე რომ, როგორც კი ეს აზრი თავში მომივიდა, გარკვეული პერიოდის შემდეგ გაჩნდა განხორციელების პირველი იდეა. ყველაფერი მარტივი ჩანდა - ბმულებზე წვდომის შეწყვეტა გჭირდებათ meet.company.com/user/confid — დააინსტალირეთ ლოკალური ვებ აპლიკაციის პროცესი თქვენს მანქანაზე 127.0.0.1-ზე და /etc/hosts-ში დაამატეთ სტატიკური ჩანაწერი კომპანიის დომენისთვის, რომლის მეშვეობითაც შედიხართ კონფერენციაზე, მიუთითეთ localhost-ზე. შემდეგი, ამ ვებ სერვერმა უნდა დაამუშაოს მასზე მოხვედრილი ბმული და როგორმე გადაიტანოს იგი Pidgin-ში (მაშინვე ვიტყვი, რომ ამ ეტაპზე ჯერ კიდევ არ მქონდა წარმოდგენა, თუ როგორ მიმეცემა იგი). ხსნარს, რა თქმა უნდა, ყავარჯნების სუნი ასდის, მაგრამ ჩვენ პროგრამისტები ვართ, ყავარჯნები არ გვაშინებენ (შიტ).

შემდეგ, შემთხვევით, რატომღაც გავხსენი მოწვევის ბმული Google Chrome-ში (და ჩვეულებრივ ყოველთვის ვიყენებ Mozilla Firefox-ს). და ჩემდა გასაკვირად, ვებ გვერდი სრულიად განსხვავებულად გამოიყურებოდა - არ არსებობდა მომხმარებლის მონაცემების შეყვანის ფორმა და გვერდზე შესვლისთანავე გაჩნდა მოთხოვნა რაღაცის გახსნის გზით. xdg- ღია. უბრალოდ გასართობად ვაწკაპუნებ "დიახ" და ჩნდება შეცდომის შეტყობინება - ბმული lync15:confjoin?url=https://meet.company.com/user/confid ვერ იხსნება. ჰმ. როგორია ეს xdg-open და რა ჭირდება, რომ ასეთი ლინკები გაიხსნას? დოკუმენტაციის შემდგომი წაკითხვამ აჩვენა, რომ ეს არის GUI დამმუშავებელი, რომელიც ეხმარება ასოცირებული აპლიკაციების გაშვებას ან პროტოკოლებით uri სქემისთვის ან კონკრეტული ფაილის ტიპებით. ასოციაციების კონფიგურაცია ხდება mime-ის ტიპის რუკების საშუალებით. ასე რომ, ჩვენ ვხედავთ, რომ ჩვენ ვაწარმოებთ შესაბამისი აპლიკაციის ძიებას დასახელებული ური სქემისთვის lync15 და ბმული გადაეცემა xdg-open-ს, რომელიც შემდეგ, თეორიულად, უნდა გადასცეს რომელიმე აპლიკაციას, რომელიც პასუხისმგებელია ამ ტიპის ბმულზე. რაც, რა თქმა უნდა, არ გვაქვს ჩვენს სისტემაში. თუ არა, მაშინ რას აკეთებენ ისინი ღია კოდის სამყაროში? მართალია, ჩვენ თვითონ დავწერთ.

სამყაროში შემდგომი ჩაძირვა Linux და განსაკუთრებით გრაფიკული გარსის (სამუშაო მაგიდის გარემო, DE) მუშაობის შესწავლისას, სხვათა შორის, ჩემთვის ეს Xfce-ია Linux Mint-მა აჩვენა, რომ აპლიკაციები და მათთან დაკავშირებული mime ტიპები, როგორც წესი, პირდაპირ იწერება .desktop გაფართოების მქონე მალსახმობ ფაილებში. კარგი, რატომაც არა? მე შევქმნი აპლიკაციის მარტივ მალსახმობს, რომელიც უბრალოდ გაუშვებს Bash სკრიპტს და ბეჭდავს კონსოლში გადაცემულ არგუმენტს. მე უბრალოდ ჩავრთავ მალსახმობის ფაილს:

[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;

კონსოლიდან ვხსნი xdg-open-ს, გავდივარ იმავე ლინკს, რომელიც მოდის ბრაუზერიდან და... საზიზღარი. ისევ ამბობს, რომ მას არ შეუძლია ბმულის დამუშავება.

როგორც ირკვევა, მე არ განვაახლე ასოცირებული mime-ტიპების დირექტორია ჩემს აპლიკაციასთან. ეს კეთდება მარტივი ბრძანებით:

xdg-mime default lync.desktop x-scheme-handler/lync15

რომელიც უბრალოდ არედაქტირებს ფაილს ~/.config/mimeapps.list.

სცადეთ ნომერი 2 xdg-ღია ზარით - და ისევ მარცხი. არაფერი, სირთულეები არ გვაშინებს, არამედ მხოლოდ ჩვენს ინტერესს აღძრავს. და ბაშის მთელი ძალით შეიარაღებული (ანუ მიკვლევა), ჩვენ პირველ რიგში ჩავრთავთ გამართვას. აქ მნიშვნელოვანია აღინიშნოს, რომ xdg-open არის მხოლოდ shell სკრიპტი.

bash -x xdg-open $url

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

xdg-open-ის ინტერიერში გადახედვისას აღმოვაჩინე, რომ ის აანალიზებს გარემოსდაცვითი სხვადასხვა პარამეტრებს და კონტროლს გადასცემს ან რომელიმე ინსტრუმენტს კონკრეტული DE-სთვის დამახასიათებელი ფაილის ბმულების გასახსნელად, ან აქვს სარეზერვო ფუნქცია. open_generic

open_xfce()
{
if exo-open --help 2>/dev/null 1>&2; then
exo-open "$1"
elif gio help open 2>/dev/null 1>&2; then
gio open "$1"
elif gvfs-open --help 2>/dev/null 1>&2; then
gvfs-open "$1"
else
open_generic "$1"
fi

if [ $? -eq 0 ]; then
exit_success
else
exit_failure_operation_failed
fi
}

მე სწრაფად ჩავრთავ აქ მცირე ჰაკს, მიღებული არგუმენტის ანალიზით და თუ ჩვენი კონკრეტული ქვესტრიქონი მდებარეობს იქ lync15:, შემდეგ დაუყოვნებლივ გადავცემთ კონტროლს ფუნქციას open_generic.

სცადეთ ნომერი 3 და როგორ ფიქრობთ, იმუშავა? ჰო, ახლა, რა თქმა უნდა. მაგრამ შეცდომის შეტყობინება უკვე შეიცვალა, ეს უკვე პროგრესია - ახლა მეუბნებოდა, რომ ფაილი ვერ მოიძებნა და ფაილის სახით დამიწერა არგუმენტად გადასული იგივე ლინკი.

ამჯერად ეს ფუნქცია აღმოჩნდა is_file_url_or_path, რომელიც აანალიზებს შეყვანისთვის გადაცემულ ფაილის ბმულს: file:// ან ფაილის გზას ან სხვა რამეს. და შემოწმებამ არ იმუშავა სწორად იმის გამო, რომ ჩვენს პრეფიქსს (url სქემას) აქვს ნომრები, ხოლო რეგულარული გამოხატულება ამოწმებს მხოლოდ სიმბოლოთა ნაკრების, რომელიც შედგება :alpha: წერტილებისა და ტირეებისგან. rfc3986 სტანდარტის კონსულტაციის შემდეგ ერთიანი რესურსის იდენტიფიკატორი გაირკვა, რომ ამჯერად მაიკროსოფტი არაფერს არღვევს (თუმცა ასეთი ვერსია მქონდა). მხოლოდ სიმბოლოების კლასი :alpha: შეიცავს მხოლოდ ლათინური ანბანის ასოებს. მე სწრაფად ვცვლი რეგულარულ შემოწმებას ალფანუმერულზე. დასრულდა, საოცარი ხარ, ყველაფერი საბოლოოდ იწყება, კონტროლი ყველა შემოწმების შემდეგ გადაეცემა ჩვენს სკრიპტის აპლიკაციას, ჩვენი ბმული ნაჩვენებია კონსოლზე, ყველაფერი ისეა, როგორც უნდა იყოს. ამის შემდეგ, მე ვიწყებ ეჭვი, რომ exo-open-თან დაკავშირებული ყველა პრობლემა ასევე გამოწვეულია ბმულის ფორმატის დადასტურებით, სქემაში არსებული ნომრების გამო. ჰიპოთეზის შესამოწმებლად, მე ვცვლი განაცხადის mime ტიპის რეგისტრაციას მხოლოდ სქემაზე ფოცხვერი და voila - ყველაფერი მუშაობს open_xfce ფუნქციის გადაფარვის გარეშე. მაგრამ ეს არანაირად არ დაგვეხმარება, რადგან კონფერენციაში შესვლის ვებ გვერდი ქმნის ლინკს lync15-თან.

ასე რომ, მოგზაურობის პირველი ნაწილი დასრულდა. ჩვენ ვიცით, როგორ ჩავჭრათ ბმულის ზარი და შემდეგ საჭიროა მისი დამუშავება და გადაცემა Pidgin-ში. იმისათვის, რომ გავიგო, თუ როგორ მუშაობს იგი შინაგანად, როდესაც მონაცემთა შეყვანისას მენიუში „შეერთდი კონფერენციას“ ბმულით, მე მოვახდინე კლონირება Sipe პროექტის Git საცავი და კვლავ მოვემზადე კოდის ჩასასვლელად. მაგრამ შემდეგ, საბედნიეროდ, კატალოგში სცენარებმა მიმიზიდა წვლილი/dbus/:

• sipe-join-conference-with-uri.pl
• sipe-join-conference-with-organizer-and-id.pl
• sipe-call-phone-number.pl
• SipeHelper.pm

ირკვევა, რომ Sipe მოდული ხელმისაწვდომია dbus-ის (სამუშაო ავტობუსის) საშუალებით ურთიერთქმედებისთვის და სკრიპტების შიგნით არის კონფერენციაზე შეერთების მაგალითები ბმულით, ან ორგანიზატორის სახელით და კონფიდენციით, ან შეგიძლიათ დაიწყოთ ზარი sip-ის საშუალებით. . ეს არის ზუსტად ის, რაც გვაკლდა.

ნაბიჯი 2. ავტომატური შეერთების დამმუშავებლის დანერგვა

ვინაიდან Pearl-ში არის მზა მაგალითები, გადავწყვიტე უბრალოდ გამოვიყენო sipe-join-conference-with-uri.pl და შეცვალეთ იგი ცოტათი, რომ მოერგოს საკუთარ თავს. მე შემიძლია დავწერო Pearl-ში, ამიტომ განსაკუთრებული სირთულეები არ შემქმნია.

სკრიპტის ცალ-ცალკე ტესტირების შემდეგ, ჩავწერე მისი ზარი ფაილში lync.desktop. და ეს იყო გამარჯვება! კონფერენციის შეერთების გვერდზე შესვლისას და xdg-open-ის გაშვების დაშვებისას, Pidgin-ის კონფერენციის ამომხტარი ფანჯარა ავტომატურად გაიხსნება. როგორ გამიხარდა.
წარმატებებით წახალისებულმა, გადავწყვიტე იგივე გამეკეთებინა ჩემი მთავარი ბრაუზერის, Mozilla Firefox-ისთვის. მელას მეშვეობით შესვლისას იხსნება ავტორიზაციის გვერდი და ბოლოში არის ღილაკი შეუერთდით საოფისე კომუნიკატორის გამოყენებით. სწორედ მან მიიქცია ჩემი ყურადღება. ბრაუზერში მასზე დაწკაპუნებისას ის მიდის მისამართზე:

conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio

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

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

"დააყენეთ პერსონალური პროტოკოლის დამმუშავებელი Firefox-ში" - მე შევედი ინტერნეტში ამ კითხვით. stackoverflow-ზე რამდენიმე დისკუსიის გავლის შემდეგ (და სად ვიქნებოდით მის გარეშე), როგორც ჩანს, პასუხი ნაპოვნია. თქვენ უნდა შექმნათ სპეციალური პარამეტრი შესახებ: config (რა თქმა უნდა, foo-ს ჩანაცვლება conf-ით):

network.protocol-handler.expose.foo = false

ჩვენ ვქმნით, ვხსნით ლინკს და... არავითარი იღბალი. ბრაუზერი, თითქოს არაფერი მომხდარა, ამბობს, რომ არ იცის ჩვენი აპლიკაცია.

მე ვკითხულობ ოფიციალურ დოკუმენტაციას Mozilla-სგან პროტოკოლის რეგისტრაციის შესახებ, არის ასოციაციების დარეგისტრირების შესაძლებლობა თავად gnome დესკტოპზე (რა თქმა უნდა, foo-ს შეცვლა conf-ით):

gconftool-2 -s /desktop/gnome/url-handlers/foo/command '/path/to/app %s' --type String
gconftool-2 -s /desktop/gnome/url-handlers/foo/enabled --type Boolean true

ვრეგისტრირდები, ვხსნი ბრაუზერს... და ისევ წვერს.

აქ არის სტრიქონი დოკუმენტაციიდან ჩემს თვალში:

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

- სემიონ სემენიჩი
-აჰ

ჩვენ არ ვაჭერთ ბმულს, მაგრამ ვებ გვერდი უბრალოდ ცვლის window.location-ს Javascript-ის საშუალებით. ვწერ მარტივ html ფაილს conf პროტოკოლის ლინკით, ვხსნი ბრაუზერში, ვაჭერ ლინკს - Yos! იხსნება ფანჯარა, რომელშიც იკითხება, რომელ აპლიკაციაში უნდა გავხსნათ ჩვენი ბმული და იქ უკვე გვაქვს ჩვენი Lync აპლიკაცია სიაში - ჩვენ გულწრფელად დავრეგისტრირდით ყველა შესაძლო გზით. ფანჯარაში არის ჩამრთველი "დაიმახსოვრეთ არჩევანი და ყოველთვის გახსენით ბმულები ჩვენს აპლიკაციაში", მონიშნეთ, დააწკაპუნეთ OK. და ეს მეორე გამარჯვებაა - იხსნება კონფერენციის ფანჯარა. ამავდროულად, კონფერენციების გახსნა მუშაობს არა მხოლოდ ბმულზე დაწკაპუნებისას, არამედ ჩვენ მიერ კონფერენციაზე საჭირო მიერთების გვერდიდან გადასვლისას.

მერე შევამოწმე, წავშალე პარამეტრები network.protocol-handler.expose.conf არანაირად არ იმოქმედა Fox-ის პროტოკოლის მუშაობაზე. ბმულებმა განაგრძო მუშაობა.

დასკვნა

მე ავტვირთე მთელი ჩემი ნამუშევარი GitHub საცავში; ყველა რესურსის ბმულები იქნება სტატიის ბოლოს.
მაინტერესებს ნებისმიერი ადამიანისგან გამოხმაურების მიღება, ვისაც ჩემი ნამუშევრის გამოყენება სურს. მინდა აღვნიშნო, რომ ყველაფერი მხოლოდ ჩემი სისტემისთვის შევიმუშავე. Linux Mint-ია, ამიტომ ზოგიერთი სხვა დისტრიბუცია ან სამუშაო მაგიდა შეიძლება არ იმუშაოს ამ ვერსიასთან. სინამდვილეში, ამაში თითქმის დარწმუნებული ვარ, რადგან xdg-open-ში მხოლოდ ერთი ფუნქცია დავაპაჩე, რომელიც სპეციფიკურია ჩემი DE-სთვის. თუ გსურთ სხვა სისტემების ან სამუშაო მაგიდების მხარდაჭერის დამატება, გთხოვთ, გამომიგზავნოთ pull request GitHub-ზე.

მთელ პროექტს 1 საღამო დასჭირდა.

ბმულები:

• პროტოკოლის რეგისტრაცია Mozilla-ში
• D-ავტობუსი (ვიკიპედია)
• rfc3986 URI
• პროექტი Github-ზე

წყარო: www.habr.com