What non-GUI programs (daemons) use glib?
I use glib quite a bit in non-GUI programming, especially for FUSE filesystems. Lots of routines to complement glibc, things like hash tables, a linked list implementation, a cross-platform threading library - lots of useful stuff for general-purpose programming. I think of it like C's version of Boost.
On my Ubuntu system apt-cache rdepends libglib2.0-0 gives me, among many others:
amanda-server (backup software)
bitlbee (IRC <-> various IM proxy)
blktool (tool to tune block device parameters; not a daemon AFAIU)
collectd (system statistics collection and monitoring daemon)
consolekit (framework for defining and tracking users, sessions and seats)
devicekit-disks (abstraction for enumerating block devices)
devicekit-power (abstraction for power management)
(I got bored at this point)
This lists package rather than actual binary dependencies; it's possible (but I don't think likely) that some of these packages ship GUI applications that depend on glib.
Let's take, say, consolekit and verify:
dpkg -L consolekit tells me the daemon is /usr/sbin/console-kit-daemon, and ldd /usr/sbin/console-kit-daemon tells me it depends on libglib, libgthread, libgmodule, libgobject, libgio, but no GUI stuff. So here you are, a genuine daemon using glib.
Irssi, an IRC client with support for scripts.
GStreamer is built upon GLib/GObject.
Most notable in my memory is libpurple aside from its GUI counterpart Pidgin
Related
I'm looking for an advice about the software that did not catch my eye during a few days of searches.
Is there any software solution for deployment of multiple projects at once that operates at the level of source-building package manager (like ports, portages, or nix), but could be resided locally?
As for details, we have few loosely connected software projects with the following traits:
Projects are written mostly on C/C ++ and Python, but more languages are represented as a minor mixture (Haskell, Rust, Perl)
Projects are grouped together within git superprojects with certain build/deployment presets carefully tuned for particular environments (and adapted for particular purposes by subset of boolean-like options)
We have already done with well-elaborated CMake build scripts for C++ projects that do support options, build configurations, exporting targets, and so on. It would be expensive to switch from it now.
We are forced to deal with various Linux distributions (from Gentoo and Ubuntu to Debian and CentOS).
We need an unifying build&deployment tool for various environments. The CMake does not integrate well with non-compiling languages (e.g. does not natively support local Python installations via virtualenv).
Instead of changing the things we already developed, I would like to use them in the manner the OS package manager does. For my vision, it should be something pretty similar to the so-called meta-build tool. In fact, the Gentoo Portages are pretty close:
Easy customization with simple boolean options (useflags, profiles)
Delegation of the building procedures to the reliable and customizable tools designed and well-tested especially for this purpose (CMake, autotools, Bazel, etc.)
Offers an ability to change the target compiler installation and specify the building process in a clear declarative way with a standardized instructions set.
Portages can not be ran locally, though (and have other unrelated flaws).
I have to become very confident before switching the whole build system to something like Meson or Bazel or whatever else I could find up to the moment.
Update
To be more specific, I could refer to what we have done up to the moment. The one of the superprojects we're maintaining deals with particular scientific experiment:
All the sub-projects are listed as git submodules
A simple BASH-script maintaining the entire build-install-deploy lifecycle
The presets referring particular settings for a concrete environment are represented as BASH sources and are included by this maintaining shell script.
As few days more had come with no result, I coming up with intention to write my own solution based on experience we already gained due to these shell scripting activity.
For a similar task Bob was developed some time ago. If you still need a build system it might be worth a look. There are some small tutorials available as well as a complex basement example build a linux from scratch.
Basically it is just a environment for a controlled execution of bash scripts with dependency and variant handling, CI integration, IDE support,..
Take a look at Sparrow - Linux scripting platform, it supports projects hierarchy and tasks - configurable scripts, where configuration is made in declarative way in Yaml, Json formats. This hopefully might address many if not all the needs you've mentioned here.
Disclosure - I am the tool author.
I am using the Ruby Daemon-kit to setup a services that does various background operations for my Rails application.
It works fine when I call in on the commandline:
./bin/bgservice
How do I go about creating a daemon initd starter script for it, so that it will autostart on reboot?
There's a few approaches:
You could write /etc/init.d/ scripts that could be placed into the /etc/rc?.d/ directories (or wherever they live on your target distributions). Some details on this mechanism can be found in the Debian policy guidelines and openSUSE initscript tutorial. There's an annoying number of distribution-specific idiosyncrasies in initscripts, so don't feel about writing a simple one and asking distributions to contribute 'better' ones tailored for their environment. (For example, any Debian-derived distribution will provide the immensely useful start-stop-daemon(8) helper, but it is sorely missing from other distributions.)
You could write upstart job specifications for the distributions that support upstart (which I think is Ubuntu, Google ChromeOS, Fedora, .. more?). upstart documentation is still pretty weak, but there are some details and plenty of examples in /etc/init/ on Ubuntu, probably the same location in other distributions that use upstart. Getting the dependencies correct may be some work across all distributions, but upstart job specifications look far simpler to write and maintain than initscripts.
You could add lines to /etc/inittab on distributions that still support the standard SysV-init inittab(5) file. This would only be useful if your program doesn't do the usual daemon fork(2)/setsid(2)/fork(2) incantation, as init uses the pid it gets from fork(2) to determine if your program needs to be restarted.
Modern Vixie cron(8) supports a #reboot specifier in crontab(5) files. This can be used both by the system crontab as well as user crontabs, which might be nice if you just want to run the program as your usual login account.
As the author of daemon-kit I've avoided making any init-style scripts due to coping with the various distributions and they're migrations from old init-V style to newer upstart/insserv, saving myself a nightmare.
How I recommend to do this is to use the god config-generator, and ensure god is started on boot (by runit or some other means), and god starts the daemon up initially and keeps it running.
At best I'll expand daemon-kit to be able to generate runit scripts for boot...
HTH.
Looking to execute a perl script on a remote machine via a Perl script. Appears one option is to use system() function and create an ssh key so the password is not required. Which leads me to the focus of this question, the other option appears to be to install and run one of these perl modules:
Net::SSH
Net::SSH2
Net::OpenSSH
Besides the protocol used, what else should I be comparing with these Perl modules?
The Net::OpenSSH documentation has a section describing the pros and cons of each. Here are some excerpts related to the ones you are asking about, but the documentation lists more:
Net::SSH is just a wrapper around any
SSH binary commands available on the
machine. It can be very slow as they
establish a new SSH connection for
every operation performed.
Net::SSH2 is much better than
Net::SSH::Perl, but not completely
stable yet. It can be very difficult
to install on some specific operative
systems and its API is also limited,
in the same way as Net::SSH::Perl.
Net::OpenSSH has a very perlish
interface. Most operations are
performed in a fashion very similar to
that of the Perl builtins and common
modules (i.e. IPC::Open2).
However, choice of platform may limit your options.
On the other hand, Net::OpenSSH does
not work on Windows, not even under
Cygwin.
Granted, the list is biased towards Net::OpenSSH, but it gives you an idea of the major differences between the modules.
Sometimes I see people use http://codepad.org as a way to quickly run/test their Perl snippets (it supports doing that with a wide variety of languages, from C to Scheme to Perl).
It's pretty obvious that there must be some limitations as to what code/features can be tested with codepad - does anyone know what those limitations are for Perl runner?
I'll get the ball rolling on my own observation: not every CPAN module is available :(
Mostly based on their "about" page:
codepad only supports Perl 5.8.0
Presumably, like any Perl install, not every module (CPAN or otherwise) is present.
As a specific example, List::MoreUtils is missing.
As a sub-limitation, they seem to run on Linux. So any Windows specific modules would certainly be out.
It's in a chroot jail with system calls restrictions. Among other things this seems to prevent file creation (my snippets creating files in a current directory or /tmp both errored out, as well as File::Temp calls)
codepad code is executed on a virtual machine. Behind firewalls. And buried in a bunker. So certain functionality is probably disabled - especially networking/internet one. The exact "about" quote is:
The supervisor processes run on virtual machines, which are firewalled such that they are incapable of making outgoing connections.
The machines that run the virtual machines are also heavily firewalled, and restored from their source images periodically.
It's easier to just run Perl code locally. It's easy to install multiple versions of Perl and to track separate module repositories. It's also not hard to run just about any operating system you want in a virtual machine. Why you'd need anyone's else's service to do what you can do better yourself is beyond me.
Whenever I work on a system of any flavor that has a particular way of handling package management, I try to stick with that standard for managing my Perl modules. "When in Rome, etc."
For example, on a Win32 system using ActivePerl, I use PPM for everything and use the great PPM::Make. On a RedHat system I prefer to use RPMs.
Now I am working on a Debian system, and find myself in need of a way to turn an arbitrary CPAN or CPAN style distribution into a deb.
Google shows options like dh-make-perl, CPANPLUS::Dist::Deb and CPAN::Packager::Builder::Deb.
Does anyone with experience with these different tools have any recommendations as to what to use or avoid?
What's the best way to handle building deb files from standard CPAN modules?
Update:
I found an article by Hans Dieter Piercy on this subject - he suggests, for his own needs, CPANPLUS tools. Under some circumstances he recommends dh-make-perl. Jeremiah Foster (who wrote the article brian d foy points to) responds to HDP and makes a case for dh-make-perl.
There's also a post on idimmu.net that describes using dh-make-perl.
ATM, I'm leaning toward dh-make-perl, since that has been thrice recommended (brian d foy as proxy for Jeremy Foster, the idimmu.net author and hillu) vs once for CPANPLUS
dh-make-perl does a good job in taking care of the repetitive and heavy lifting and guessing information from the sources. It has worked correctly for almost all of the CPAN modules that I have packaged up as Debian packages (official or for in-house use only).
That said, the resulting package should only be considered as a starting point for a proper Debian packages. dh-make-perl puts warning notes into the automatically generated such as debian/control (i.e. description of the package and dependencies) and debian/copyright (licensing information).
In response to Manni, I believe that it is a great idea to work with the tools that the OS or distribution provides for package management, not against them. In the case of Debian, this means putting stuff into .deb packages and installing those. Perl's build tools and CPAN do a great job of providing a cross-platform build environment and for distribution of the source code, but compared to package management tools in modern Linux distributions, they perform suboptimally, simply because extra manual intervention is often required that is less easily automated across multiple machines than rolling up a package.
(For one-off and test installations, installing into /usr/local/ and using stow(8) as a poor man's package manager may be okay.)
Even if you are just building the packages for your own use, consider contacting the Debian Perl Group and have someone sponsor an upload to Debian if you feel that the module in question is of use for other people.
I suggest you ask the Debian Perl Maintainers group, rather than here on SO. Just mail the address shown as maintainer on any odd package:
Debian Perl Group <pkg-perl-maintainers#lists.alioth.debian.org>
Back in the day, I added a few modules to Debian, and just 'did it by hand'. I still maintain some. That isn't hard either. but the group now maintains way more package, and has tools.
Jeremiah Foster published an article about turning Perl distros into Debian packages in the Spring 2009 issue of The Perl Review.
There is a very good step by step here as well. (also with links to other good resources and some decent comments. [it is dated 2005, but still mostly relavent and many comments much more recent])
http://www.debian-administration.org/articles/78
here is the debian perl policy (also linked to in article)
http://www.debian.org/doc/packaging-manuals/perl-policy/
You won't like this, but I really think that you should not do this at all. The various Perl Debian packages aren't for developers that need certain Perl modules on their machines. They were built because other applications need them and users want or might want those applications.
Please take a look at the answers to this question before doing something that you probably should not be doing.