I'm working on a Linux system (a based of OpenWRT version) that has not much storage (<3MB) and no active internet connection, however I need to be able to publish to a MQTT-Broker some outputs. Is there a way for me to install just the publisher part of Mosquitto to save space or another way to solve this issue?
Without a LOT more information about the system this question is basically impossible to answer. e.g. we have no idea about what OS is being used...
But for a system with such tightly constrained storage your best option will probably to build the components you need from scratch that way you have complete control over what gets installed.
You could build the mosquitto tools and then strip them before copying just the binary you want (and any require libraries) to the system.
If you install from pretty much any Linux package management system you are likely to get all the tools plus man pages which will inflate the install footprint.
EDIT -
But all that said, a quick look at the available packages for OpenWRT implies that the existing packages that include both the broker and the command line tools would use 129kb (99 + 30 and is less if you don't need SSL 85 + 28) when installed (this assumes the pre-requisites are already installed)
https://openwrt.org/packages/table/start?dataflt%5BDescription_wiki*%7E%5D=mosquitto
Related
Our requirement is to create a container for legacy apps over docker.
We don't have the operating system support/application server support available, nor do we have knowledge to build them from scratch.
But we have a physical instance of the legacy app running in our farm.
We could get an ISO image from our server team if required, our question is if we get this ISO image can we export this as a docker image?
if yes, please let me know if there is any specific procedure or steps associated with it.
if no, please tell me why? and the possible workarounds for the same.
if we get this ISO image can we export this as a docker image?
I don't think there is an easy way (like push-the-export-button) to do this. Explanation follows...
You are describing a procedure taking place in the Virtual Machine world. You take a snapshot of a server, move the .iso file somewhere else and create a new VM that will run on a Hypervisor.
Containers are not VMs. They "contain" all the bytes that a service needs to run but not a whole operating system. They are supposed to run as processes on the host.
Workarounds:
You will have to get your hands dirty. This means that you will have to find out what the legacy app uses (for example Apache + PHP + MySql + app code) and build it from scratch with Docker.
Some thoughts:
containers are supposed to be lightweight. For example one might use one container for the database, another one for the Apache etc... Your case looks like you are moving towards a fat container that has everything inside.
Depending on what the legacy technology is, you might hit a wall... For example, if we are talking about something working with old php, mysql you might find ready-to-use images on hub.docker.com. But if the legacy app is a financial system written in cobol, I don't know what your starting point might be...
You will need to reverse engineer the application dependencies from the artifacts that you have in access to. This means recovering the language specific dependencies (whether python, java, php, node, etc). And any operating system level packages/dependencies that are required.
Essentially you are rebuilding the contents of that ISO image inside your docker file using OS package installation tools like apt, language level tools like pip, PECL, PEAR, composer, or maven, and finally the files that make up the app code.
So, for example: a PHP application might be dependent on having build-essential and php-mysql installed in the OS. Then the app may be dependent on packages like twig and monolog loaded through composer. If you are using SASS you may need to install ruby as well.
Your job is to track all these down and create a docker file that reproduces the iso image. If you are using a common stack like a J2EE app in tomcat, or a php app fronted by apache or ngnix, there will be base docker images that will get you most of the way to where you need to go.
It does look like there are some tools that can do this for you automatically: Dependency Walker equivalent for Linux?. I can't vouch for any of them. But you can also use command line tools. For example this will give you a list of all the user installed packages on a fedora system:
sudo dnf history userinstalled
When an app is using a dependency manager like composer or pip, there is usually a file that lists all the language specific dependencies.
At the end of the process you'll have a portable legacy app that can be easily deployed anywhere with a minimal footprint.
As one of the comments rightly points out, creating a VM from the ISO image is another way forward that will be much easier to accomplish. The application dependencies won't be explicit, but maybe that's ok for your use case.
I deleted my Linux install and recently tried OpenBSD but i am not sure how to set up a GUI environment and xserver. I have a R9 290 gpu and I saw that it should be supported by the radeon driver however I don't know how to download or configure it.
thank you.
All drivers are included in the default install and should Just Work©. That said, your Radeon GPU may need firmware whose license prevents OpenBSD from including it. Running fw_update should install it if it's needed.
Other than that, you just need to configure X. Everything's included in the base system, including the window managers cwm and fvwm. If you want another, you can install it from ports. To configure X, read the very well-written FAQ entry.
Enjoy!
I use Vagrant + virtualBox and a Debian 8 / Ubuntu image for my development environments.
I want to use nix for provisioning, but I can't get nixOS to work completely right (ie. with networking, provisioning...), but I'd more than happy to switch. So I'm falling back to nix + Debian 8 or nix + Ubuntu to mimic the production server.
I can't quite get the differences between user packages and system packages and what is preferable to use in in my context, in order to be able to reuse that into a production server.
Should I install packages with nix -i, or edit the configuration.nix file ?
Whether you should install packages into the system profile or into a user profile depends on what you'd like to achieve. There is no single right answer. Instead, both types of installing packages have different pros and cons.
System packages are defined in a global configuration file that typically resides in /etc/nixos/configuration.nix. Users other than root can typically not edit that file and thus cannot add or remove packages from the list. Packages defined in there will be installed as part of nixos-rebuild and they'll be available in $PATH to every user of your system. If any of those packages don't compile for some reason, however, then you cannot rebuild your system, i.e. you may find yourself in a situation where you cannot update your kernel because, say, nano doesn't compile. People who follow the master branch of the Nixpkgs git repository may experience this problem frequently, but it doesn't happen so much for users of the unstable or the release-x.y channels.
User packages can be installed, updated, and de-installed by any user on your system without the need for super-user privileges. One user's packages will not be visible to another user (unless she makes a conscious effort to import them into $PATH). Thus, it's possible for two users to install two different versions of the same package.
If a user does not regularly update her profile, then you'll accumulate old packages in your Nix store that cannot be garbage collected. This may be a problem or a feature, depending on how you look at it. System packages, on the other hand, are all updated every time you update the system, so those tend to have a smaller disk space footprint.
Personally, I prefer to keep my system profile as small as possible; I install packages mostly into user profiles with nix-env. I know many people, however, who do the exact opposite and we all get along fine. :-)
Torch is a scientific computing framework with wide support for machine learning algorithms. It is easy to use and efficient, thanks to an easy and fast scripting language, LuaJIT, and an underlying C/CUDA implementation.
Q:
Is there a way to install torch on MS Windows 8.1?
I got it installed and running on Windows (although not 8.1, but I don't expect the process to be different) following instructions in this repository; it's now deprecated, but wasn't deprecated few months ago when I built it. The new instructions point to torch/torch7 repository, but it has a different structure and I haven't been able to build it on Windows yet.
There are instructions on how to install Torch7 from luarocks, but you may run into issues on windows as well; I haven't tried this process. It seems like there is no official support for Windows yet, but some work is being done by contributors (there is a link to a pull request in that thread).
Based on my experience, compiling that deprecated repo may be your best option on Windows at the moment.
Update (7/9/2015): I've recently submitted several changes that fix compilation issues with mingw, so you may try the most recent version of torch7 and follow the build instructions in the ticket. Note that the changes only apply to the core lib and additional libraries may need similar changes.
This webpage hosted by New York University recommends installing a Linux virtual machine in order to run Torch7 on Windows through Linux. Another option would off course be to install a Linux dist in parallel with Windows 8.
Otherwise, if you don't mind running an older version of Torch, there is a Windows installer for Torch5 at SourceForge.
I think to use a GPU from inside the virtual machine, the processor and the motherboard should not only support VT-x , but VT-d should be supported too.
But the question is, if I use a CPU with VT-d supported, do you think there will be a significant loss in PCIe connections efficiency?
From what I understand,
VT-d is important if I want to give the virtual machines direct access to my hardware components (like PCI Express cards). Like directly attach graphics card to vm instead of host machine. Isn't that mean that the PCIe connections efficiency will be the same just like if it was the host?
I want to set-up vicidial in my local computer server any information or a document for that?
I googled but I can't find exact resource.
I googled below links.
Link 1
Link 2
Thanks in advance.
Vicidial is an Open Source Predictive AutoDialer based on Asterisk with PHP/MySQL/Perl coding.
Installation of Vicidial is only viable on a Linux machine.
There are several locations with Scratch Install instructions for Ubuntu and CentOS. In fact, the Vicidial Wiki has a list of a few of them: http://wiki.vicidial.org/index.php/VICI:Installation
Most are quite old except for the Goautodial.com which has instructions for CentOS installation by adding the goautodial repositories and then just upgrading the OS to get all the necessary packages.
If you're not using CentOS or Ubuntu and none of those instructions work for your purpose, beware that Vicidial installation is not easy. It is MUCH better to dedicate a machine to the purpose by installing from Vicibox.com's .iso image which will wipe the computer clean. The installation becomes easy and then you need only argue with configuration.
If you can not dedicate a machine to this purpose, you should take the earlier suggestion of a Virtual server (vSphere or Virtualbox both work for Vicibox.com's .iso installer), but beware that you'll only be able to have one or two agents on the virtual dialer at the most. Luckily, if you do get the virtual vicidial working, it is possible to backup the virtual server's database and install it on a hardware based server later to bring everything with you without having to do it all over.