nikolaos_ Δημοσ. 25 Νοεμβρίου 2010 Share Δημοσ. 25 Νοεμβρίου 2010 Ωραίο το νέο theme του φόρουμ αλλά από ό,τι κατάλαβα ακόμα κάνετε fine-tuning. Δοκίμασα να βρω παλιά θέματα του φόρουμ σχετικά με το πώς κάνουν εκκίνηση (boot) τα Linux, αλλά μου προέκυψε σφάλμα. Στο θέμα μου τώρα. Ο υπολογιστής μου μένει πολλές ώρες αναμμένος και εκτελεί κατά διαστήματα μερικά script που έγραψα στο bash. (1) Τα scripts ενεργοποιούνται μόνο όταν κάνω login (με το δικό μου username/password) στο GNOME. Στο System->Preferences->Startup Applications πρόσθεσα σαν εντολές τα scripts. Ωστόσο αυτό δε μου φτάνει, θέλω να εκτελούνται προτού κάνω login. Πώς μπορώ να το επιτύχω; (2) Τα scripts ενεργοποιούνται ανά τακτά διαστήματα και άτακτα, δηλαδή οποτεδήποτε συντρέχουν κάποια γεγονότα (π.χ. υπάρχει κάποια διαφορά μεταξύ δυο αρχείων). Δε χρησιμοποιώ γι' αυτό το cron αλλά αφήνω να εκτελούνται συνέχεια βάζοντας sleep και if εντολές. Υπάρχει κάποια ιδέα ή συμβουλή για το cron ; Να το χρησιμοποιώ ή όχι; (3) Πώς μπορώ να μάθω το boot sequence του συστήματός μου; Τι φορτώνει κατά την εκκίνηση; (4) Αυτό είναι άσχετο με το θέμα, αλλά για οικονομία να μην ανοίγω 2-3 το συμμαζεύω εδώ: εδώ και ένα εξάμηνο κατεβάζω (είτε με το software center, είτε με το synaptic package manager, είτε σε κονσόλα με apt-get) διάφορα προγράμματα, τα οποία χρησιμοποιώ μια φορά και ξεχνάω ότι τα εγκατέστησα. Και άντε όσα επηρεάζουν το desktop μπορώ να τα εντοπίσω (στο Applications), αυτά που είναι στην κονσόλα και κρύβονται στο /usr/bin από πού μπορείς να τα βλέπεις σε μια συνοπτική μορφή; Υπάρχει κανένα σχετικό utility ; Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
jim_p Δημοσ. 25 Νοεμβρίου 2010 Share Δημοσ. 25 Νοεμβρίου 2010 Λιγη θεωρια. Στο λινουξ η εκκινηση χωριζεται σε runlevels. Υπαρχουν τα 0,1,2,3,4,5,6 και S και τα οσα εκτελουνται στο καθενα ειναι στους φακλους /etc/rcX.d/ (σαν symlinks) για τις debianoειδεις διανομες. 0 και 6 ειναι ο τερματισμος και η επανεκκινηση αντιστοιχα, 1 ειναι το single-user mode (ή "recovery mode" οπως το εχει το ubuntu), 2-5 ειναι τα multi user οπου ξεκιναει το γραφικο περιβαλλον κλπ και S ειναι εκεινο που εκτελειται πριν απο ολα τα αλλα και περιλαμβανει βασικες διαδικασιες του συστηματος, πχ να φορτωσει τον πυρηνα στη μνημη, να κανει αναγνωριση συσκευων κλπ. Το default runlevel για τις debianοειδεις ειναι το 2 και οριζεται μεσα στο /etc/inittab. ΟΛΑ τα services που μπορουν να τρεξουν, απο αυτο που φορτωνει τον πυρηνα μεχρι αυτο που φορτωνει τον gdm (πρωτο και τελευταιο αντιστοιχα), εχουν το σκριπτακι τους στο /etc/init.d/ και απο ενα symlink στο αναλογο runlevel που πρεπει να τρεξουν. Το symlink εχει μια ιδιαιτερη ονομασια η οποια δηλωνει α) τη σειρα με την οποια θα τρεξει, πχ το portmap για nfs τρεχει παντα μετα το service του δικτυου και πριν το nfs και β) το αν θα τρεχει στο εκαστοτε runlevel ή οχι. Για την 1η περιπτωση, το service του δικτυου τρεχει ως S15networking το portmap ειναι S16portmap το nfs λιγο μετα με S17nfs-common. Για την 2η περιπτωση, το service του bluetooth που δεν το θελω να τρεχει στην εκκινηση ειναι K01bluetooth ενω το hddtemp ειναι S01hddtemp και τρεχει (τυχαια αριθμηση). Οπως καταλαβαινεις, ενα απλο symlink του σκριπτ σου στο /etc/rc2.d/, βαλμενο στο τελος της σειρας, αρκει για να κανεις τη δουλεια σου. Αλλα τοτε θα τρεχει με δικαιωματα root, που δεν ξερω αν το θες. Το cron εχει νοημα να το χρησιμοποιησεις αν πχ θες το σκριπτ να εκτελειται καθε ωρα, αρα να απορροφησει την sleep που εχει μεσα του. Για αυτο που λες με τα πακετα δεν υπαρχει αλλη λυση απο το να τα ψαξεις στο synaptic σαν εγκατεστημενα. Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
NullScan Δημοσ. 25 Νοεμβρίου 2010 Share Δημοσ. 25 Νοεμβρίου 2010 Συγκεκριμένα για το /bin ή και για το /usr/bin ή τέλος πάντων για όλα τα directories που έχουν binary executable αρχεία που εγκαθίστανται από το apt μπορείς να χρησιμοποιήσεις ένα script που θα βασίζεται στο dpkg, κάπως έτσι: >for i in `ls /bin`; do dpkg -S $i | awk 'BEGIN { FS=":" }; {print $1}'; done και αυτό θα σου εμφανίσει μιά λίστα με όλα τα πακέτα στα οποία ανήκουν τα περιεχόμενα του /bin. Τώρα επειδή αυτή η λίστα θα είναι μεγάλη και πολλά πακέτα ίσως να επαναλαμβάνονται μπορείς να κάνεις ένα redirect σε ένα αρχείο και να φιλτράρεις τα πακέτα για να τα δείς ένα ένα με κάποιον text editor. Κάπως έτσι δηλαδή: >for i in `ls /bin`; do dpkg -S $i | awk 'BEGIN { FS=":" }; {print $1}' >> installed_packages.txt; done Και μετά δίνεις ένα >cat installed_packages.txt | sort -u | less και τα βλέπεις όλα. Άν στο παραπάνω one liner αλλάξεις το /bin με οποιοδήποτε άλλο directory του συστήματός σου θέλεις να δείς ποιός έχει εγκαταστήσει τί εκεί μέσα, φυσικά και μπορείς. Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
nikolaos_ Δημοσ. 26 Νοεμβρίου 2010 Μέλος Share Δημοσ. 26 Νοεμβρίου 2010 Λιγη θεωρια. ... 0 και 6 ειναι ο τερματισμος και η επανεκκινηση αντιστοιχα, 1 ειναι το single-user mode (ή "recovery mode" οπως το εχει το ubuntu), 2-5 ειναι τα multi user οπου ξεκιναει το γραφικο περιβαλλον κλπ και S ειναι εκεινο που εκτελειται πριν απο ολα τα αλλα και περιλαμβανει βασικες διαδικασιες του συστηματος, πχ να φορτωσει τον πυρηνα στη μνημη, να κανει αναγνωριση συσκευων κλπ. Το default runlevel για τις debianοειδεις ειναι το 2 και οριζεται μεσα στο /etc/inittab. ΟΛΑ τα services που μπορουν να τρεξουν, απο αυτο που φορτωνει τον πυρηνα μεχρι αυτο που φορτωνει τον gdm (πρωτο και τελευταιο αντιστοιχα), εχουν το σκριπτακι τους στο /etc/init.d/ και απο ενα symlink στο αναλογο runlevel που πρεπει να τρεξουν. Το symlink εχει μια ιδιαιτερη ονομασια ... Οπως καταλαβαινεις, ενα απλο symlink του σκριπτ σου στο /etc/rc2.d/, βαλμενο στο τελος της σειρας, αρκει για να κανεις τη δουλεια σου. Αλλα τοτε θα τρεχει με δικαιωματα root, που δεν ξερω αν το θες. Δε βρήκα αρχείο /etc/inittab. Αν θέλω να αλλάξω runlevel στην εκκίνηση πού πάω; Επίσης στο /etc/rc2.d δε βρίσκω κάτι που παραπέμπει στο gdm. Από πού τρέχει; Από ό,τι κατάλαβα, οπότε με διορθώνεις, κατά την εκκίνηση: (1) Πρώτα παίρνει ένα-ένα τα symlinks του /etc/rcS.d, με τη σειρά όπως των αριθμών μετά το S στο κάθε όνομα του symlink, αγνοώντας όσα αρχίζουν από K, και εκτελεί το σκριπτάκι που δείχνει κάθε symlink, που συνήθως τα σκριπτάκια βρίσκονται στο /etc/init.d. Τα σκριπτάκια στο /etc/init.d μπορούν να εκτελούν προγράμματα, που βρίσκονται σε οποιοδήποτε μέρος του filesystem. (2) Κατόπιν κάνει την ίδια δουλειά με τα symlinks που βρίσκονται στο /etc/rc2.d (3) Αρκεί λοιπόν να πάρω το δικό μου σκριπτάκι mybootscript.sh από το /home/nikolaos/bin και να φτιάξω ένα symlink μέσα στο rc2.d με το κατάλληλο όνομα S94* για να πάει στην 94η σειρά περίπου στο τέλος των υπολοίπων > root@mymachine:/etc/rc2.d # ln -s /home/nikolaos/bin/mybootscript.sh S94-mysx root@mymachine:/etc/rc2.d # ../update-rc.d script defaults το οποίο δε με ενοχλεί πολύ που θα τρέχει με δικαιώματα root, εκτός αν δε μπορώ να το σκοτώσω με sudo kill -9 pid ή >nikolaos@mymachine:~ $ sudo killall mybootscript.sh (4) Για εγκυκλοπαιδικούς περισσότερο λόγους, αν θέλω να τρέχει με δικαιώματα user nikolaos ή ενός άλλου, αρκετά ισχυρού user που θα φτιάξω, τι να κάνω; Το cron εχει νοημα να το χρησιμοποιησεις αν πχ θες το σκριπτ να εκτελειται καθε ωρα, αρα να απορροφησει την sleep που εχει μεσα του. Το ζήτημα είναι ότι στο μέλλον το σκριπτάκι θα τρέχει ένα κώδικα αναλόγως ένα event, ένα ping συγκεκριμένα. Για αυτο που λες με τα πακετα δεν υπαρχει αλλη λυση απο το να τα ψαξεις στο synaptic σαν εγκατεστημενα. Η απάντηση σε αυτό το θέμα που πήρα από τον επόμενο μετά από σένα με καλύπτει προς το παρόν. Περιμένω το feedback... Ευχαριστώ όλους. Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
NullScan Δημοσ. 26 Νοεμβρίου 2010 Share Δημοσ. 26 Νοεμβρίου 2010 Δε βρήκα αρχείο /etc/inittab. Αν θέλω να αλλάξω runlevel στην εκκίνηση πού πάω; Επίσης στο /etc/rc2.d δε βρίσκω κάτι που παραπέμπει στο gdm. Από πού τρέχει; Το Ubuntu δέν χρησιμοποιεί κάποιον SysV-like (άν μου επιτρέπεται ο όρος) για init daemon. Χρησιμοποιεί το Upstart. Θεωρία: Το startup sequence ενός *NIX συστήματος έχει ώς εξής: 1. Το BIOS φορτώνει τον boot loader που βρίσκεται στα 512 πρώτα bytes του αποθηκευτικού μέσου. 2. Ο boot loader ξέρει πού θα βρεί το λειτουργικό σύστημα που θα επιλέξει ο χρήστης. Αμέσως μετά την επιλογή, ο kernel (γιατί αυτό ειναι το λειτουργικό σύστημα) αυτός φορτώνεται στη μνήμη. 3. Αμέσως μετά το initialization βασικών subsystems για την minimum λειτουργία του λειτουργικού, η διαδικασία εκκίνησης παραδίδεται στον init daemon που λέγαμε παραπάνω. Γι αυτό και άν κοιτάξεις τα running processes οποιουδήποτε *NIX θα δείς οτι το 1ο που έχει εκτελεστεί (και παραμένει running καθ' όλη τη διάρκεια που το σύστημα τρέχει) έχει το ProcessID 1 και λέγεται init. Και εδώ είναι που υπάρχουν παραλλαγές. Εκτός από την τοποθεσία του daemon (που πάντα βρίσκεται στο /sbin) οι υπόλοιπες λειτουργίες του δέν είναι ίδιες σε όλες τις διανομές. Δές πχ το OpenRC που χρησιμοποιεί το gentoo. Το Debian από την άλλη έχει το sysvinit. To Ubuntu, με το Upstart μπορεί να ζήσει και χωρίς το /etc/inittab αλλά άν υπάρχει θα το χρησιμοποιήσει. Άρα για να απαντήσω στην ερώτησή σου, άν θέλεις να αλλάξεις το default rrunlevel, ή θα φτιάξεις ένα inittabg το οποίο έχω την εντύπωση οτι το Upstart θα σεβαστεί ή θα ψάξεις να δείς πώς το Upstart το χειρίζεται αυτό. Εδώ δέν μπορώ να σε βοηθήσω παραπάνω γιατί δέν έχω Ubuntu πουθενά. Όσον αφορά τον gdm ψάξε λίγο καλύτερα: >sudo find /etc/ -name '*gdm*' Από ό,τι κατάλαβα, οπότε με διορθώνεις, κατά την εκκίνηση: (1) Πρώτα παίρνει ένα-ένα τα symlinks του /etc/rcS.d, με τη σειρά όπως των αριθμών μετά το S στο κάθε όνομα του symlink, αγνοώντας όσα αρχίζουν από K, και εκτελεί το σκριπτάκι που δείχνει κάθε symlink, που συνήθως τα σκριπτάκια βρίσκονται στο /etc/init.d. Τα σκριπτάκια στο /etc/init.d μπορούν να εκτελούν προγράμματα, που βρίσκονται σε οποιοδήποτε μέρος του filesystem. (2) Κατόπιν κάνει την ίδια δουλειά με τα symlinks που βρίσκονται στο /etc/rc2.d Σωστά. (3) Αρκεί λοιπόν να πάρω το δικό μου σκριπτάκι mybootscript.sh από το /home/nikolaos/bin και να φτιάξω ένα symlink μέσα στο rc2.d με το κατάλληλο όνομα S94* για να πάει στην 94η σειρά περίπου στο τέλος των υπολοίπων > root@mymachine:/etc/rc2.d # ln -s /home/nikolaos/bin/mybootscript.sh S94-mysx root@mymachine:/etc/rc2.d # ../update-rc.d script defaults το οποίο δε με ενοχλεί πολύ που θα τρέχει με δικαιώματα root, εκτός αν δε μπορώ να το σκοτώσω με sudo kill -9 pid ή >nikolaos@mymachine:~ $ sudo killall mybootscript.sh Όχι ακριβώς. Άν ρίξεις μιά ματιά στα init scripts, θα δείς οτι τα περισσότερα χρησιμοποιούν ένα binary που λέγεται start-stop-daemon (της Red Hat αν δέν κάνω λάθος, αυτή ήταν η άχρηστη πληροφορία της ημέρας ). Όλα τα init scripts επειδή ότι τρέχουν τρέχει καθ' όλη τη διάρκεια της παραμονής του συστήματος στο συγκεκριμένο runlevel δέν πρέπει να σταματούν το execution flow. Άν εσύ δηλαδή πάς στο ενδιάμεσο των προγραμμάτνω που πρέπει να εκτελεστού και τρέξεις μιά εντολή την οποία δέν φροντίσεις να την στείλεις στο background με κάποιο τρόπο, δέν θα τελειώσει ποτέ η διαδικασία εκκίνησης όλων των init scripts του runlevel. Και αυτό κάνει η start-stop-daemon. Δέν ξέρω τί είναι αυτό που θέλεις να κάνεις ακριβώς αλλά όταν φτιάξεις το script σου φρόντισε το init script που θα προσθέσεις στο runlevel που θέλεις και το οποίο θα ξεκινάει το δικό σου να κάνει όλους τους απαραίτητους ελέγχους και θα έχει κάποια διαδικασία daemon-ize του script ή του προγράμματος που θέλεις να τρέξεις. Μέσα σε αυτό το script δε, μπορείς να προσθέσεις και τον τρόπο με τον οποίο θα τερματίζεται η λειτουργεία του script σου, αντί δηλαδή να δίνεις pkill ή killall θα δίνεις /etc/init.d/yourscript stop. Για να το καταφέρεις αυτό θα χρειαστεί να διαβάσεις λίγο bash scripting για να δείς τον χειρισμο των cases που περνιούνται σαν παράμετροι στο script σου (star/stop/restart/status κτλ) και διάβασε και το man του start-stop-daemon. (4) Για εγκυκλοπαιδικούς περισσότερο λόγους, αν θέλω να τρέχει με δικαιώματα user nikolaos ή ενός άλλου, αρκετά ισχυρού user που θα φτιάξω, τι να κάνω;Το ζήτημα είναι ότι στο μέλλον το σκριπτάκι θα τρέχει ένα κώδικα αναλόγως ένα event, ένα ping συγκεκριμένα. Ότι τρέχει μέσω του init daemon τρέχει με δικαιώματα root. Άν εσώ δέν το θέλεις αυτό, τότε υπάρχουν 2 λύσεις. 1. Ρυθμίζεις το script σου να τρέχει με την εντολή sudo nikolaos 2. Ξεχνάς την λύση του init script και φτιάχνεις ένα cron job που θα τρέχει ανα όποιο χρονικό διάστημα θέλεις. Άν βέβαια αυτό που θέλεις να τρέξεις πρέπει να τρέχει πάντα και όχι να σταματάει και να ξεκινάει ανα Χ χρονικό διάστημα το ξεχνάς και αυτό και πάς στην 3η λύση που θέλει και λίγο περισσότερο διάβασμα: Set User ID bit: Στα *NIX υπάρχει η δυνατότητα να σετάρεις ένα bit στα file permissions οποιουδήποτε αρχείου ώστε όταν αυτό εκτελέιται, να μήν εκτελείται με τα δικαιώματα του χρήστη που το εκτέλεσε αλλά με τα δικαιώματα του χρήστη στον οποίο ανήκει το αρχείο. Άν κάνεις ls -l filename τότε θα σου επιστραφεί κάτι τέτοιο: >-rw-r--r-- 1 OwnerUsername GroupName 8.8M 30-08-2010 14:47 filename Τα OwnerUsername και GroupName είναι τα ονόματα του χρήστη και του group χρηστών στα οποία ανήκει το αρχείο filename. Στην 1η στήλη βλέπεις τί δικαιώματα έχουν πάνω σε αυτό το αρχείο 1ον Ο ιδιοκτήτης (OwnerUsername), οι χρήστες που ανήκους στο group GroupName, και τέλος όλου οι υπόλοιποι χρήστες του συστήματος Εξαιρόντας την 1η παύλα, αυτά σηματοδοτούνται από τα γράμματα r, w, x και σημαίνουν Read, Write και eXecute αντίστοιχα. Άν δέν υπάρχει κάποιο από αυτά, σημαίνει οτι δέν υπάρχουν τα αντίστοιχα δικαιώματα για αυτή την κατηγορία χρηστών. Στο παραπάνω δηλαδή ο ιδιοκτήτης έχει read και write, το group έχει read μόνο καθώς και όλοι οι υπόλοιποι χρήστες του συστήματος έχουν read μόνο. Άν αυτό ήταν εκτελέσιμο αρχείο θα έβλεπες και το x εκείπου θα έδινε δικαιώματα ο ιδιοκτήτης. Άν τώρα θέσεις το SUID bit, θα το έβλεπες κάπως έτσι: >-rwsr-xr-x 1 OwnerUsername GroupName 8.8M 30-08-2010 14:47 filename Το bit αυτό το θέτεις εκτελώντας την εντολή chmod +s filename. Και για να πειστείς προσπάθησε να κάνεις touch ένα αρχείο κάπου που ο χρήστης σου δέν έχει δικαιώματα, π.χ. στο /opt >touch /opt/test Θα σου βγάλει permission denied. Μετά κάνε αυτό: >sudo chmod +s /bin/touch και ξαναπροσπάθησε σαν κανονικός χρήστης να κάνεις πάλι touch στο /opt. Θα δείς οτι όχι μόνο το αρχείο δημιιουργήθηκε αλλά έχει και δικαιώματα root. Αυτά τα ολίγα και ότι χρειαστείς εδώ είμαστε. EDIT: Να προσθέσω κάτι όσον αφορά το SUID. Το bit αυτό δέν κληρονομείται. Αυτό σημαίνει οτι άν φτιάξεις ένα script που καλέι την touch στο παράδειγμα παραπάνω και θέσεις SUID στο script, η touch πάλι θα σου επιστρέψει permission denied. Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
nikolaos_ Δημοσ. 26 Νοεμβρίου 2010 Μέλος Share Δημοσ. 26 Νοεμβρίου 2010 Αυτό που θέλω να κάνω είναι να αυτοματοποιήσω κάποιες εργασίες που εκτελούν τα σκριπτάκια μου, όταν εγώ δεν είμαι παρών στον υπολογιστή και τον αφήνω αναμένο 24/7. Τα σκριπτάκια κατεβάζουν ανά διαστήματα δεδομένα (εικόνες από μετ. δορυφόρους για να γίνω πιο συγκεκριμένος) και κάνουν backup. Όπως το έχω μέχρι στιγμής, πρέπει να παραμένει ο χρήστης nikolaos ανοικτός, γιατί τα σκριπτάκια αρχίζουν να εκτελούνται αμέσως μόλις κάνει login στο GNOME. Αυτό θέλω να το αποφύγω, αλλά με logout τα σκριπτάκια διακόπτονται. Σκέφτηκα να δημιουργήσω έναν άλλο χρήστη π.χ. autonik και να έχω συνέχεια logged in αυτόν αντί για τον nikolaos αλλά τελικά πάλι το ίδιο αποτέλεσμα προκύπτει, αφού (1) τα ίδια σκριπτάκια που θα βάλω μέσα το autonik θα πρέπει να χρησιμοποιούν αρχεία και καταλόγους που θα βρίσκονται κάτω από το /home/nikolaos. (2) κάποιο bash terminal ή GNOME θα πρέπει να ανοίγει για να γίνει login ο autonik, άρα αντί να αφήνω εκτεθειμένο τον nikolaos θα αφήνω τον autonik. Υπόψη ότι οι μόνοι τρόποι που γνωρίζω να γίνεται εκτέλεση-στην-εκκίνηση ενός σκριπτ είναι με το .bashrc (κάθε φορά που ανοίγει terminal, ευνοήτως όχι επιθυμητό) και το System->Preferences->Startup Applications του GNOME. Επίσης ο root σαν εκτελεστής των σκριπτ είναι καλή περίπτωση αλλά αν έχω κάνει κάποιο λάθος, οι συνέπειές του είναι επιεικώς ανεξέλεγκτες. Αλλά αυτά που εκτελούν τα σκριπτ που έχω φτιάξει δε φέρνουν την καταστροφή, οπότε προς το παρόν δεν έχω πρόβλημα. Το Ubuntu δέν χρησιμοποιεί κάποιον SysV-like (άν μου επιτρέπεται ο όρος) για init daemon. Χρησιμοποιεί το Upstart. Ένα upstart-job μαζί με άλλα αρχεία βρήκα στο /lib/init > nikolaos@mymachine:~ $ ls /lib/init fstab readlink rw splash-functions-base upstart-job usplash-fsck-functions.sh vars.sh Όχι ακριβώς. Άν ρίξεις μιά ματιά στα init scripts, θα δείς οτι τα περισσότερα χρησιμοποιούν ένα binary που λέγεται start-stop-daemon (της Red Hat αν δέν κάνω λάθος, αυτή ήταν η άχρηστη πληροφορία της ημέρας ). Όλα τα init scripts επειδή ότι τρέχουν τρέχει καθ' όλη τη διάρκεια της παραμονής του συστήματος στο συγκεκριμένο runlevel δέν πρέπει να σταματούν το execution flow. Άν εσύ δηλαδή πάς στο ενδιάμεσο των προγραμμάτων που πρέπει να εκτελεστούν και τρέξεις μιά εντολή την οποία δέν φροντίσεις να την στείλεις στο background με κάποιο τρόπο, δέν θα τελειώσει ποτέ η διαδικασία εκκίνησης όλων των init scripts του runlevel. Και αυτό κάνει η start-stop-daemon. Δέν ξέρω τί είναι αυτό που θέλεις να κάνεις ακριβώς αλλά όταν φτιάξεις το script σου φρόντισε το init script που θα προσθέσεις στο runlevel που θέλεις και το οποίο θα ξεκινάει το δικό σου να κάνει όλους τους απαραίτητους ελέγχους και θα έχει κάποια διαδικασία daemon-ize του script ή του προγράμματος που θέλεις να τρέξεις. Μέσα σε αυτό το script δε, μπορείς να προσθέσεις και τον τρόπο με τον οποίο θα τερματίζεται η λειτουργεία του script σου, αντί δηλαδή να δίνεις pkill ή killall θα δίνεις /etc/init.d/yourscript stop. Για να το καταφέρεις αυτό θα χρειαστεί να διαβάσεις λίγο bash scripting για να δείς τον χειρισμο των cases που περνιούνται σαν παράμετροι στο script σου (star/stop/restart/status κτλ) και διάβασε και το man του start-stop-daemon. Ακολουθώντας τα sym-links του /etc/rc2.d, διάβασα το περιεχόμενο σε καναδυό scripts που βρίσκονται βέβαια στο /etc/init.d, όπως και το αρχείο /etc/init.d/skeleton. Έχω κάνει αρκετά πράγματα σε bash οπότε δεν είχα δυσκολία να καταλάβω τη δομή του skeleton όσο και των άλλων scripts που του μοιάζουν. Ένα μέρος από τα αρχεία του /etc/init.d είναι με τη σειρά τους sym-links προς το /lib/init/upstart-job, το οποίο είναι ιδιαιτερότητα του ubuntu όπως μου είπες, οπότε θα το αφήσω έξω από τη συζήτηση. Τα υπόλοιπα είναι scripts που ακολουθούν τη δομή του skeleton, τα οποία ωστόσο τρέχουν (με το start-stop-daemon) αντίστοιχους daemons και όχι "daemon-ized scripts". Ούτε βέβαια με ενδιαφέρει να κατασκευάσω έναν daemon σε C αντί για bash script. Έτσι λοιπόν, δε βρήκα κάποιο υπόδειγμα για να βάλω τα σκριπτάκια μου μέσα στο skeleton και φυσικά να σώσω το αποτέλεσμα στο /etc/init.d και μετά να φτιάξω και το sym-link κατάλληλα ονοματισμένο στο /etc/rc2.d και τέλος να εκτελέσω το update-rc.d (!!) Η επόμενη ιδέα που σκέφτηκα πριν λίγο διαβάζοντας, είναι μήπως να πειράξω το /etc/rc.local που είναι το τελευταίο script που διαβάζει μετά την εκτέλεση όσων βρίσκονται στα /etc/rcX.d Ότι τρέχει μέσω του init daemon τρέχει με δικαιώματα root. Άν δέν το θέλεις αυτό, τότε υπάρχουν 2 λύσεις. 1. Ρυθμίζεις το script σου να τρέχει με την εντολή sudo nikolaos 2. Ξεχνάς την λύση του init script και φτιάχνεις ένα cron job που θα τρέχει ανα όποιο χρονικό διάστημα θέλεις. Άν βέβαια αυτό που θέλεις να τρέξεις πρέπει να τρέχει πάντα και όχι να σταματάει και να ξεκινάει ανα Χ χρονικό διάστημα το ξεχνάς και αυτό και πάς στην 3η λύση που θέλει και λίγο περισσότερο διάβασμα: Set User ID bit: Στα *NIX υπάρχει η δυνατότητα να σετάρεις ένα bit στα file permissions οποιουδήποτε αρχείου ώστε όταν αυτό εκτελέιται, να μήν εκτελείται με τα δικαιώματα του χρήστη που το εκτέλεσε αλλά με τα δικαιώματα του χρήστη στον οποίο ανήκει το αρχείο. ... Άν αυτό ήταν εκτελέσιμο αρχείο θα έβλεπες και το x εκεί που θα έδινε δικαιώματα ο ιδιοκτήτης. Άν τώρα θέσεις το SUID bit, θα το έβλεπες κάπως έτσι: >-rwsr-xr-x 1 OwnerUsername GroupName 8.8M 30-08-2010 14:47 filename Το bit αυτό το θέτεις εκτελώντας την εντολή chmod +s filename. ... Αυτά τα ολίγα και ότι χρειαστείς εδώ είμαστε. EDIT: Να προσθέσω κάτι όσον αφορά το SUID. Το bit αυτό δέν κληρονομείται. Αυτό σημαίνει οτι άν φτιάξεις ένα script που καλέι την touch στο παράδειγμα παραπάνω και θέσεις SUID στο script, η touch πάλι θα σου επιστρέψει permission denied. To SUID είναι καλή ιδέα, δεδομένου ότι ο root θα πρέπει όντως να τρέχει τα σκριπτάκια με δικαιώματα nikolaos. Ωστόσο ακόμη δεν έχω ξεκαθαρίσει πώς να βάλω το σκριπτ να τρέχει πριν το login. Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
NullScan Δημοσ. 26 Νοεμβρίου 2010 Share Δημοσ. 26 Νοεμβρίου 2010 Εν ολίγοις καταλαβαίνω οτι ένα απλό cron job θα σου λύσει όλα τα προβλήματα. Μπορείς να ρυθμίσεις τον cron να εκτελεί το script που κατεβάζει τις εικόνες σου όσο συχνά θέλεις, δέν χρειάζεται να έχεις κάνει login και δέν θα έχεις και θέματα με τα permissions. Άν χρειαστείς βοήθεια στην σύνταξη του cron εδώ είμαστε αν και δέν νομίζω να αντιμετωπίσεις πρόβλημα είναι πολύ απλό. Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
nikolaos_ Δημοσ. 26 Νοεμβρίου 2010 Μέλος Share Δημοσ. 26 Νοεμβρίου 2010 Δεν αποκλείεται όντως να αρκεί το cron, αν κι έχω μια δυσπιστία. Θα διαβάσω και θα ενημερώσω. Βρήκα επίσης και αυτό εδώ. http://embraceubuntu.com/2005/09/07/adding-a-startup-script-to-be-run-at-bootup/ Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
nikolaos_ Δημοσ. 26 Νοεμβρίου 2010 Μέλος Share Δημοσ. 26 Νοεμβρίου 2010 Κατέβασα και χρησιμοποίησα το scheduled tasks του GNOME το οποίο αλλάζει το crontab. Ωστόσο υπάρχει κάτι που θέλω να προσθέσω: Θέλω το script να εκτελείται μια φορά, μόλις γίνει το boot, και μετά στο χρονοδιάγραμμα που έχει καθοριστεί. Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
gtroza Δημοσ. 27 Νοεμβρίου 2010 Share Δημοσ. 27 Νοεμβρίου 2010 από τον επόμενο μετά από σένα κακοδιατυπωμένο script το σωστό είναι "απ'τον NullScan" θα φάμε κανένα διαγώισμα πριν τις γιορτές και θα ησυχάσουμε ! ευχαριστούμε καθηγητές και ανήσυχους συμφοιτητές και γι' αυτό το ενδιαφέρον workshop ! _ χρόνια πολλά nikolaos_ προκαταβολικά ! . Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
NullScan Δημοσ. 27 Νοεμβρίου 2010 Share Δημοσ. 27 Νοεμβρίου 2010 Εάν καταλήξεις στη λύση του cron τότε δέν θα βάλεις κανένα sleep στο script σου. Θα το αφήσεις να κάνει μόνο το wget και να τερματίζει και θα πείς στον cron πόσο συχνά θέλεις να εκτελείται. Καλημέρα στον gtroza και σε όλους Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
nikolaos_ Δημοσ. 1 Δεκεμβρίου 2010 Μέλος Share Δημοσ. 1 Δεκεμβρίου 2010 Μέχρι στιγμής το crontab όπως το ρύθμισα δουλεύει μια χαρά. Στα σκριπτάκια αφαίρεσα τα sleep. Ευχαριστώ για την βοήθεια! Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
NullScan Δημοσ. 2 Δεκεμβρίου 2010 Share Δημοσ. 2 Δεκεμβρίου 2010 Παρακαλώ! Συνδέστε για να σχολιάσετε Κοινοποίηση σε άλλες σελίδες άλλες επιλογές
Προτεινόμενες αναρτήσεις
Αρχειοθετημένο
Αυτό το θέμα έχει αρχειοθετηθεί και είναι κλειστό για περαιτέρω απαντήσεις.