[INFO] ARCH Linux: Απόψεις, Ερωτήσεις, Σχόλια

[tritonas00]

Τι γίνεται σε αυτήν την περίπτωση;

 

pacman -Syy

[mphxths]

Για πειτε μου ρε παιδια το εξης.

 

Εψαχνα drivers για τον εκτυπωτη μου για λινουξ.Με τα πολλα τους βρηκα αλλα σε rpm/deb.Περασα το deb πακετακι στο ubuntu που χω σε vm και δουλεψε κομπλε ο εκτυπωτης.

Υπαρχει τροπος να εγκατασταθει rpm ή deb πακετο σε arch ?Θα εγκατασταθει σωστα ή θα γινει κανα παρατραγουδο ?

[corrupted]

Αν ειναι rpm για Fedora, το πιθανοτερο ειναι πως θα σου παιξει μια χαρα.

 

pacman -S rpmextract

mkdir foo

cp package.rpm foo

cd foo

rpmextract.sh package.rpm

 

Και τοποθετεις manually τα αρχεια που εγιναν extract, στους φακελους του συστηματος...

[mphxths]

οταν ακουω την λεξη "manually"..με πιανει η καρδια μου...

[corrupted]

Μπορεις να εκτελεσεις το rpmextract.sh κατω απο το / βαζοντας χυμα το rpm εκει, και να πανε τα αρχεια κατευθειαν στους φακελους του συστηματος. Απλα χειροκινητα βλεπεις που παει τι.

[martinoff]

το θεωρώ απίθανο αυτό που βρήκες να μην υπάρχει στο aur

εάν δεν υπάρχει θα φτιάξεις ένα απλό PKGBUILD

εάν δυσκολευτείς τράβα από abs/aur ένα PKGBUILD για άλλον εκτυπωτή και κανε το δικό σου παρόμοιο αλλάζοντας τα source

[mphxths]

O εκτυπωτης ειναι EPSON και στο AUR εχει ενα καρο μοντελα εκτος απο την σειρα του δικου μου.

 

Περα απο τα rpm/deb πακετα , εχει και τα αντιστοιχα sources.Λες να τα χτισω απο τα sources εεε..?χμμ

[martinoff]

όλο το aur από source είναι

 

επειδή θα σου σκάσει στο checksum αν βάλεις άλλο PKGBUILD, με makepkg -g έχεις τα νέα

 

[tritonas00]

ή makepkg --skipinteg

[martinoff]

ή makepkg --skipinteg

πες μου ότι έχεις trustall στο pacman και τέλος !

 

 

από άνθρωπο με sudo passwordless τι περιμένεις τσ τσ τσ

 

το ssh σου να φανταστώ τρέχει σε port 22 ε ?

 

 

[mphxths]

τελικα εκανα extract το rpm πακετο.Εφτιαχνε στην ουσια καποια dirs στο /opt .Τα εριξα ολα εκει , εφτιαξα permissions και εκανα εγκατασταση τον εκτυπωτη , αφου δηλωσα χειροκινητα το ppd του απο τους νεοδημιουργηθεντες φακελους.

Τον εγκατεστησε κανονικα αλλα η δοκιμαστικη δεν τυπωθηκε ποτε

 

filter failed..καποια μπινια παιζει...παω στοιχημα ...

[tritonas00]

οχι, εχω αλλαξει την θυρα του ssh οσο να ναι ..

[firewalker]

Τώρα που το rc.conf θα πάει περίπατο... Ο systemd πως ορίζει την σειρά που ξεκινούν οι deamons;

[corrupted]

Τώρα που το rc.conf θα πάει περίπατο... Ο systemd πως ορίζει την σειρά που ξεκινούν οι deamons;

Nice question!

 

Υποθετω πως αναλογα με τα περιεχομενα του καθε αρχειου και τις παραμετρους που εχει, τοποθετειται και στην αναλογη σειρα το service.

 

man systemd.service

 

 

>
SYSTEMD.SERVICE(5)			  systemd.service			 SYSTEMD.SERVICE(5)



NAME
   systemd.service - Service unit configuration

SYNOPSIS
   systemd.service

DESCRIPTION
   A unit configuration file whose name ends in .service encodes
   information about a process controlled and supervised by systemd.

   This man page lists the configuration options specific to this unit
   type. See systemd.unit(5) for the common options of all unit
   configuration files. The common configuration items are configured in
   the generic [unit] and [install] sections. The service specific
   configuration options are configured in the [service] section.

   Additional options are listed in systemd.exec(5), which define the
   execution environment the commands are executed in, and in
   systemd.kill(5) which define the way the processes of the service are
   terminated.

   Unless DefaultDependencies= is set to false, service units will
   implicitly have dependencies of type Requires= and After= on
   basic.target as well as dependencies of type Conflicts= and Before= on
   shutdown.target. These ensure that normal service units pull in basic
   system initialization, and are terminated cleanly prior to system
   shutdown. Only services involved with early boot or late system
   shutdown should disable this option.

   If a service is requested under a certain name but no unit
   configuration file is found, systemd looks for a SysV init script by
   the same name (with the .service suffix removed) and dynamically
   creates a service unit from that script. This is useful for
   compatibility with SysV. Note that this compatibility is quite
   comprehensive but not 100%. For details about the incomptibilities see
   the Incompatibilities with SysV[1] document.

OPTIONS
   Service files must include a [service] section, which carries
   information about the service and the process it supervises. A number
   of options that may be used in this section are shared with other unit
   types. These options are documented in systemd.exec(5) and
   systemd.kill(5). The options specific to the [service] section of
   service units are the following:

   Type=
	   Configures the process start-up type for this service unit. One of
	   simple, forking, oneshot, dbus, notify or idle.

	   If set to simple (the default value if BusName= is not specified)
	   it is expected that the process configured with ExecStart= is the
	   main process of the service. In this mode, if the process offers
	   functionality to other processes on the system its communication
	   channels should be installed before the daemon is started up (e.g.
	   sockets set up by systemd, via socket activation), as systemd will
	   immediately proceed starting follow-up units.

	   If set to forking it is expected that the process configured with
	   ExecStart= will call fork() as part of its start-up. The parent
	   process is expected to exit when start-up is complete and all
	   communication channels set up. The child continues to run as the
	   main daemon process. This is the behavior of traditional UNIX
	   daemons. If this setting is used, it is recommended to also use the
	   PIDFile= option, so that systemd can identify the main process of
	   the daemon. systemd will proceed starting follow-up units as soon
	   as the parent process exits.

	   Behavior of oneshot is similar to simple, however it is expected
	   that the process has to exit before systemd starts follow-up units.
	   RemainAfterExit= is particularly useful for this type of service.

	   Behavior of dbus is similar to simple, however it is expected that
	   the daemon acquires a name on the D-Bus bus, as configured by
	   BusName=. systemd will proceed starting follow-up units after the
	   D-Bus bus name has been acquired. Service units with this option
	   configured implicitly gain dependencies on the dbus.socket unit.
	   This type is the default if BusName= is specified.

	   Behavior of notify is similar to simple, however it is expected
	   that the daemon sends a notification message via sd_notify(3) or an
	   equivalent call when it finished starting up. systemd will proceed
	   starting follow-up units after this notification message has been
	   sent. If this option is used NotifyAccess= (see below) should be
	   set to open access to the notification socket provided by systemd.
	   If NotifyAccess= is not set, it will be implicitly set to main.

	   Behavior of idle is very similar to simple, however actual
	   execution of a the service binary is delayed until all jobs are
	   dispatched. This may be used to avoid interleaving of output of
	   shell services with the status output on the console.

   RemainAfterExit=
	   Takes a boolean value that specifies whether the service shall be
	   considered active even when all its processes exited. Defaults to
	   no.

   GuessMainPID=
	   Takes a boolean value that specifies whether systemd should try to
	   guess the main PID of a service should if it cannot be determined
	   reliably. This option is ignored unless Type=forking is set and
	   PIDFile= is unset because for the other types or with an explicitly
	   configured PID file the main PID is always known. The guessing
	   algorithm might come to incorrect conclusions if a daemon consists
	   of more than one process. If the main PID cannot be determined
	   failure detection and automatic restarting of a service will not
	   work reliably. Defaults to yes.

   PIDFile=
	   Takes an absolute file name pointing to the PID file of this
	   daemon. Use of this option is recommended for services where Type=
	   is set to forking. systemd will read the PID of the main process of
	   the daemon after start-up of the service. systemd will not write to
	   the file configured here.

   BusName=
	   Takes a D-Bus bus name, where this service is reachable as. This
	   option is mandatory for services where Type= is set to dbus, but
	   its use is otherwise recommended as well if the process takes a
	   name on the D-Bus bus.

   ExecStart=
	   Takes a command line that is executed when this service shall be
	   started up. The first token of the command line must be an absolute
	   file name, then followed by arguments for the process. It is
	   mandatory to set this option for all services. This option may not
	   be specified more than once, except when Type=oneshot is used in
	   which case more than one ExecStart= line is accepted which are then
	   invoked one by one, sequentially in the order they appear in the
	   unit file.

	   Optionally, if the absolute file name is prefixed with @, the
	   second token will be passed as argv[0] to the executed process,
	   followed by the further arguments specified. If the first token is
	   prefixed with - an exit code of the command normally considered a
	   failure (i.e. non-zero exit status or abnormal exit due to signal)
	   is ignored and considered success. If both - and @ are used for the
	   same command the former must precede the latter. Unless
	   Type=forking is set, the process started via this command line will
	   be considered the main process of the daemon. The command line
	   accepts % specifiers as described in systemd.unit(5).

	   On top of that basic environment variable substitution is
	   supported. Use ${FOO} as part of a word, or as word of its own on
	   the command line, in which case it will be replaced by the value of
	   the environment variable including all whitespace it contains,
	   resulting in a single argument. Use $FOO as a separate word on the
	   command line, in which case it will be replaced by the value of the
	   environment variable split up at whitespace, resulting in no or
	   more arguments. Note that the first argument (i.e. the program to
	   execute) may not be a variable, and must be a literal and absolute
	   path name.

	   Note that this setting does not directly support shell command
	   lines. If shell command lines are to be used they need to be passed
	   explicitly to a shell implementation of some kind. Example:
	   ExecStart=/bin/sh -c 'dmesg | tac'

	   For services run by a user instance of systemd the special
	   environment variable MANAGERPID is set to the PID of the systemd
	   instance.

   ExecStartPre=, ExecStartPost=
	   Additional commands that are executed before or after the command
	   in ExecStart=, respectively. Multiple command lines may be
	   concatenated in a single directive, by separating them by
	   semicolons (these semicolons must be passed as separate words). In
	   that case, the commands are executed one after the other, serially.
	   Alternatively, these directives may be specified more than once
	   with the same effect. However, the latter syntax is not recommended
	   for compatibility with parsers suitable for XDG .desktop files. Use
	   of these settings is optional. Specifier and environment variable
	   substitution is supported.

   ExecReload=
	   Commands to execute to trigger a configuration reload in the
	   service. This argument takes multiple command lines, following the
	   same scheme as pointed out for ExecStartPre= above. Use of this
	   setting is optional. Specifier and environment variable
	   substitution is supported here following the same scheme as for
	   ExecStart=. One additional special environment variables is set: if
	   known $MAINPID is set to the main process of the daemon, and may be
	   used for command lines like the following: /bin/kill -HUP $MAINPID.

   ExecStop=
	   Commands to execute to stop the service started via ExecStart=.
	   This argument takes multiple command lines, following the same
	   scheme as pointed out for ExecStartPre= above. Use of this setting
	   is optional. All processes remaining for a service after the
	   commands configured in this option are run are terminated according
	   to the KillMode= setting (see systemd.kill(5)). If this option is
	   not specified the process is terminated right-away when service
	   stop is requested. Specifier and environment variable substitution
	   is supported (including $MAINPID, see above).

   ExecStopPost=
	   Additional commands that are executed after the service was stopped
	   using the commands configured in ExecStop=. This argument takes
	   multiple command lines, following the same scheme as pointed out
	   for ExecStartPre. Use of these settings is optional. Specifier and
	   environment variable substitution is supported.

   RestartSec=
	   Configures the time to sleep before restarting a service (as
	   configured with Restart=). Takes a unit-less value in seconds, or a
	   time span value such as "5min 20s". Defaults to 100ms.

   TimeoutStartSec=
	   Configures the time to wait for start-up. If a daemon service does
	   not signal start-up completion within the configured time, the
	   service will be considered failed and be shut down again. Takes a
	   unit-less value in seconds, or a time span value such as "5min
	   20s". Pass 0 to disable the timeout logic. Defaults to 90s, except
	   when Type=oneshot is used in which case the timeout is disabled by
	   default.

   TimeoutStopSec=
	   Configures the time to wait for stop. If a service is asked to stop
	   but does not terminate in the specified time, it will be terminated
	   forcibly via SIGTERM, and after another delay of this time with
	   SIGKILL (See KillMode= in systemd.kill(5)). Takes a unit-less value
	   in seconds, or a time span value such as "5min 20s". Pass 0 to
	   disable the timeout logic. Defaults to 90s.

   TimeoutSec=
	   A shorthand for configuring both TimeoutStartSec= and
	   TimeoutStopSec= to the specified value.

   WatchdogSec=
	   Configures the watchdog timeout for a service. This is activated
	   when the start-up is completed. The service must call sd_notify(3)
	   regularly with "WATCHDOG=1" (i.e. the "keep-alive ping"). If the
	   time between two such calls is larger than the configured time then
	   the service is placed in a failure state. By setting Restart= to
	   on-failure or always the service will be automatically restarted.
	   The time configured here will be passed to the executed service
	   process in the WATCHDOG_USEC= environment variable. This allows
	   daemons to automatically enable the keep-alive pinging logic if
	   watchdog support is enabled for the service. If this option is used
	   NotifyAccess= (see below) should be set to open access to the
	   notification socket provided by systemd. If NotifyAccess= is not
	   set, it will be implicitly set to main. Defaults to 0, which
	   disables this feature.

   Restart=
	   Configures whether the main service process shall be restarted when
	   it exits. Takes one of no, on-success, on-failure, on-abort or
	   always. If set to no (the default) the service will not be
	   restarted when it exits. If set to on-success it will be restarted
	   only when it exited cleanly, i.e. terminated with an exit code of
	   0. If set to on-failure it will be restarted only when it exited
	   with an exit code not equalling 0, when terminated by a signal
	   (including on core dump), when an operation (such as service
	   reload) times out or when the configured watchdog timeout is
	   triggered. If set to on-abort it will be restarted only if it exits
	   due to reception of an uncaught signal (including on core dump). If
	   set to always the service will be restarted regardless whether it
	   exited cleanly or not, got terminated abnormally by a signal or hit
	   a timeout.

   SuccessExitStatus=
	   Takes a list of exit status definitions that when returned by the
	   main service process will be considered successful termination, in
	   addition to the normal successful exit code 0 and the signals
	   SIGHUP, SIGINT, SIGTERM and SIGPIPE. Exit status definitions can
	   either be numeric exit codes or termination signal names, and are
	   separated by spaces. Example: "SuccessExitStatus=1 2 8 SIGKILL",
	   ensures that exit codes 1, 2, 8 and the termination signal SIGKILL
	   are considered clean service terminations.

   RestartPreventExitStatus=
	   Takes a list of exit status definitions that when returned by the
	   main service process will prevent automatic service restarts
	   regardless of the restart setting configured with Restart=. Exit
	   status definitions can either be numeric exit codes or termination
	   signal names, and are separated by spaces. Defaults to the empty
	   list, so that by default no exit status is excluded from the
	   configured restart logic. Example: "RestartPreventExitStatus=1 6
	   SIGABRT", ensures that exit codes 1 and 6 and the termination
	   signal SIGABRT will not result in automatic service restarting.

   PermissionsStartOnly=
	   Takes a boolean argument. If true, the permission related execution
	   options as configured with User= and similar options (see
	   systemd.exec(5) for more information) are only applied to the
	   process started with ExecStart=, and not to the various other
	   ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=,
	   ExecStopPost= commands. If false, the setting is applied to all
	   configured commands the same way. Defaults to false.

   RootDirectoryStartOnly=
	   Takes a boolean argument. If true, the root directory as configured
	   with the RootDirectory= option (see systemd.exec(5) for more
	   information) is only applied to the process started with
	   ExecStart=, and not to the various other ExecStartPre=,
	   ExecStartPost=, ExecReload=, ExecStop=, ExecStopPost= commands. If
	   false, the setting is applied to all configured commands the same
	   way. Defaults to false.

   NonBlocking=
	   Set O_NONBLOCK flag for all file descriptors passed via
	   socket-based activation. If true, all file descriptors >= 3 (i.e.
	   all except STDIN/STDOUT/STDERR) will have the O_NONBLOCK flag set
	   and hence are in non-blocking mode. This option is only useful in
	   conjunction with a socket unit, as described in systemd.socket(5).
	   Defaults to false.

   NotifyAccess=
	   Controls access to the service status notification socket, as
	   accessible via the sd_notify(3) call. Takes one of none (the
	   default), main or all. If none no daemon status updates are
	   accepted from the service processes, all status update messages are
	   ignored. If main only service updates sent from the main process of
	   the service are accepted. If all all services updates from all
	   members of the service's control group are accepted. This option
	   should be set to open access to the notification socket when using
	   Type=notify or WatchdogUsec= (see above). If those options are used
	   but NotifyAccess= not configured it will be implicitly set to main.

   Sockets=
	   Specifies the name of the socket units this service shall inherit
	   the sockets from when the service is started. Normally it should
	   not be necessary to use this setting as all sockets whose unit
	   shares the same name as the service (ignoring the different suffix
	   of course) are passed to the spawned process.

	   Note that the same socket may be passed to multiple processes at
	   the same time. Also note that a different service may be activated
	   on incoming traffic than inherits the sockets. Or in other words:
	   The Service= setting of .socket units doesn't have to match the
	   inverse of the Sockets= setting of the .service it refers to.

   StartLimitInterval=, StartLimitBurst=
	   Configure service start rate limiting. By default services which
	   are started more often than 5 times within 10s are not permitted to
	   start any more times until the 10s interval ends. With these two
	   options this rate limiting may be modified. Use StartLimitInterval=
	   to configure the checking interval (defaults to 10s, set to 0 to
	   disable any kind of rate limiting). Use StartLimitBurst= to
	   configure how many starts per interval are allowed (defaults to 5).
	   These configuration options are particularly useful in conjunction
	   with Restart=, however apply to all kinds of starts (including
	   manual), not just those triggered by the Restart= logic. Note that
	   units which are configured for Restart= and which reach the start
	   limit are not attempted to be restarted anymore, however they may
	   still be restarted manually at a later point from which point on
	   the restart logic is again activated. Note that systemctl
	   reset-failed will cause the restart rate counter for a service to
	   be flushed, which is useful if the administrator wants to manually
	   start a service and the start limit interferes with that.

   StartLimitAction=
	   Configure the action to take if the rate limit configured with
	   StartLimitInterval= and StartLimitBurst= is hit. Takes one of none,
	   reboot, reboot-force or reboot-immediate. If none is set, hitting
	   the rate limit will trigger no action besides that the start will
	   not be permitted.  reboot causes a reboot following the normal
	   shutdown procedure (i.e. equivalent to systemctl reboot),
	   reboot-force causes an forced reboot which will terminate all
	   processes forcibly but should cause no dirty file systems on reboot
	   (i.e. equivalent to systemctl reboot -f) and reboot-immediate
	   causes immediate execution of the reboot(2) system call, which
	   might result in data loss. Defaults to none.

   Check systemd.exec(5) and systemd.kill(5) for more settings.

COMPATIBILITY OPTIONS
   The following options are also available in the [service] section, but
   exist purely for compatibility reasons and should not be used in newly
   written service files.

   SysVStartPriority=
	   Set the SysV start priority to use to order this service in
	   relation to SysV services lacking LSB headers. This option is only
	   necessary to fix ordering in relation to legacy SysV services, that
	   have no ordering information encoded in the script headers. As such
	   it should only be used as temporary compatibility option, and not
	   be used in new unit files. Almost always it is a better choice to
	   add explicit ordering directives via After= or Before=, instead.
	   For more details see systemd.unit(5). If used, pass an integer
	   value in the range 0-99.

   FsckPassNo=
	   Set the fsck passno priority to use to order this service in
	   relation to other file system checking services. This option is
	   only necessary to fix ordering in relation to fsck jobs
	   automatically created for all /etc/fstab entries with a value in
	   the fs_passno column > 0. As such it should only be used as option
	   for fsck services. Almost always it is a better choice to add
	   explicit ordering directives via After= or Before=, instead. For
	   more details see systemd.unit(5). If used, pass an integer value in
	   the same range as /etc/fstab's fs_passno column. See fstab(5) for
	   details.

SEE ALSO
   systemd(1), systemctl(8), systemd.unit(5), systemd.exec(5),
   systemd.kill(5)

NOTES
    1. Incompatibilities with SysV
	   http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities



systemd													 SYSTEMD.SERVICE(5)

 

 

[tritonas00]

Τώρα που το rc.conf θα πάει περίπατο... Ο systemd πως ορίζει την σειρά που ξεκινούν οι deamons;

 

Οριζει απο μονο του, εχω την εντυπωση, αλα dependencies.

 

Δηλαδη γνωριζει αν το Α service χρειαζεται το B για να δουλεψει, οποτε ξεκιναει το Β πρωτα και μετα το Α.

 

Καπου το ειχα διαβασει, αλλα δεν θυμαμαι που.

Επεξ/σία 26 Νοεμβρίου 2012 από tritonas00