Member
Diamond_grRun copy.com on your openSUSE Raspberry Pi
The cloud service I prefer is always ownCloud.
Here I used http://www.copy.com. It provides 15GB of disk but you can increase it.
First of all download the file
Then extract it
This will create a folder called “copy,” and in it there will be three sub-folders: “armv6h,” “x86,” and “x86_64.” The first one contains the Copy client binaries for the Raspberry Pi, the second contains the Copy client for 32-bit Linux on a PC, and the third the same client but for 64-bit Linux PCs.
$ cd armv6h
Now there are 2 ways of using copy. The CopyCmd tool and CopyConsole.
CopyCmd
List of the directories
Upload all content of local /home/user/directory/ to remote /directory
CopyConsole
The CopyConsole tool keeps a folder on your Raspberry Pi synchronized with the data on Copy.com.
The sync app runs in the background and is started like this:
This will sync the local /home/user/directory to copy.com. If you delete something from there, it'll delete from local folder as well.
Remeber to run this command everytime you restart your pi. It's better to run it manually because there is username and password that are personal (unless you created an account just for your raspberry pi).
Make your openSUSE Raspberry Pi a seedbox
Here I will show you how to setup Transmission, vftpd and suggestions for Android programs.
First of all, download and create the openSUSE SD card (resize your SD card to full size or you can mount the extra size as extra partition. Since it's not something important, then you can use full size of your SD card).
Then setup the dynamic dns service (see previous posts).
Finally set a static IP (to use it with port forward of your router).
First install transmission:
Create 2 folders for incomplete torrents and completed torrents:
Configure proper permissions for transmission:
$ chgrp transmission /torrents/complete
$ chmod 770 /torrents/incomplete
$ chmod 777 /torrents/complete
Now edit transmission settings.json file using:
$ rm /var/lib/transmission/.config/transmission/settings.json
and
$ nano /var/lib/transmission/.config/transmission/settings.json
Here is the content of your file:
"alt-speed-down": 50,
"alt-speed-enabled": false,
"alt-speed-time-begin": 540,
"alt-speed-time-day": 127,
"alt-speed-time-enabled": false,
"alt-speed-time-end": 1020,
"alt-speed-up": 50,
"bind-address-ipv4": "0.0.0.0",
"bind-address-ipv6": "::",
"blocklist-enabled": false,
"blocklist-url": "http://www.example.com/blocklist",
"cache-size-mb": 4,
"dht-enabled": false,
"download-dir": "/torrents/complete",
"download-limit": 100,
"download-limit-enabled": 0,
"download-queue-enabled": true,
"download-queue-size": 5,
"encryption": 1,
"idle-seeding-limit": 30,
"idle-seeding-limit-enabled": false,
"incomplete-dir": "/torrents/incomplete",
"incomplete-dir-enabled": true,
"lpd-enabled": false,
"max-peers-global": 200,
"message-level": 2,
"peer-congestion-algorithm": "",
"peer-limit-global": 91,
"peer-limit-per-torrent": 150,
"peer-port": 51413,
"peer-port-random-high": 65535,
"peer-port-random-low": 49152,
"peer-port-random-on-start": false,
"peer-socket-tos": "default",
"pex-enabled": false,
"port-forwarding-enabled": true,
"preallocation": 1,
"prefetch-enabled": 1,
"queue-stalled-enabled": true,
"queue-stalled-minutes": 30,
"ratio-limit": 2,
"ratio-limit-enabled": false,
"rename-partial-files": true,
"rpc-authentication-required": true,
"rpc-bind-address": "0.0.0.0",
"rpc-enabled": true,
"rpc-password": "{2dc2c41724aab07ccc301e97f56360cb35f8ba1fGVVrdHDX",
"rpc-port": 9091,
"rpc-url": "/transmission/",
"rpc-username": "transmission",
"rpc-whitelist": "*.*.*.*",
"rpc-whitelist-enabled": false,
"scrape-paused-torrents-enabled": true,
"script-torrent-done-enabled": false,
"script-torrent-done-filename": "",
"seed-queue-enabled": false,
"seed-queue-size": 10,
"speed-limit-down": 250,
"speed-limit-down-enabled": true,
"speed-limit-up": 0,
"speed-limit-up-enabled": true,
"start-added-torrents": true,
"trash-original-torrent-files": false,
"umask": 18,
"upload-limit": 100,
"upload-limit-enabled": 0,
"upload-slots-per-torrent": 14,
"utp-enabled": true
}
Username: transmission
Password: transmission
Port: 9091
Start and enable the service.
$ systemctl enable transmission-daemon
You're done. All you have to do is to open your browser to http://RASPI.IP.ADDRESS:9091/ and use the login/password (default for above config transmission/transmission)
Let's say that the file is i your pi disk. You're not at home. How can you check it? Maybe the easiest way is to setup an FTP server. Maybe the best program is vsftpd. You can install it:
Create a folder for ftp users (if it's not there).
Create a group called ftp-users.
Create a sample user called seedbox with home directory /srv/ftp/, and assign the user to ftp-users group.
Set password for the new user.
Now you should change few things:
And uncomment:
write_enable=YES
Start the service and you're done:
$ systemctl enable vsftpd
Personally I use the program filezilla but you can also use the Firefox addon FireFTP.
OK, you installed torrent server. How can you access the downloaded files from your computer? Well it's easy. Just install SAMBA. For that reason, I followed the tutorial here.
First of all, install SAMBA.
Then all you have to do is to change SAMBA configuration file.
$ nano /etc/samba/smb.cnf
Just add the following lines:
comment = Public Shares
path = /torrents/complete
writeable = Yes
only guest = Yes
create mask = 0777
directory mask = 0777
browseable = Yes
public = yes
You should restart SAMBA or you can reboot your Pi.
$ systemctl enable smb nmb
Now you can access your Pi from Nautilus (check here how to do that).
If you want to use it via android phone/tablet, you can use the program Remote Transmission
More applications are Transdrone and TorrentToise.
Set static IP on your openSUSE Raspberry Pi
In openSUSE is easier. Everything can be done under YaST.
1. Open YaST and go to Network Devices>Network Settings.
2. Then choose Statically Assigned IP Address (move with tab button and click on space button). Give the static IP you want (IP address needs to be in the same range as the router's) and as Subnet Mask, 255.255.255.0. Press Next (press enter).
3. You'll see an overview of the ethernet card.
4. Go to Hostname/DNS and add Google's DNS servers (optional).
5. Next, go to Routing and add your router ip (usually 192.168.1.1).
Now press OK, reboot and try to login again with SSH.
inadyn and openSUSE Raspberry Pi
Fortunately, there's not only this service but other services too. Just for reference, here are some (not only free):
http://www.dyndns.org
http://freedns.afraid.org
http://www.zoneedit.com
http://www.no-ip.com
http://www.easydns.com
http://www.tzo.com
http://www.3322.org
http://www.dnsomatic.com
http://www.tunnelbroker.net
http://dns.he.net/
http://www.dynsip.org
http://www.sitelutions.com
http://www.dnsexit.com
http://www.changeip.com
http://www.zerigo.com
http://www.dhis.org
https://nsupdate.info
http://duckdns.org
https://www.loopia.com
https://www.namecheap.com
https://domains.google.com
https://www.ovh.com
https://www.dtdns.com
http://giradns.com
Let's see one of them https://freedns.afraid.org. After you register, go to Dynamic DNS link (on the left top box-for members).
Add your host with type A and subdomain and domain what you like as host.
Now there's going to be a list of your host names. Right click on the Direct Link and copy the link. You should keep the alpha-numeric key. The address will be something like http://freedns.afraid.org/dynamic/update.php?[alpha-numeric-key]
Now it's time to install the client. I've found it from https://github.com/troglobit/inadyn.
1. First of all, install the needed programs to build the service.
2. Then
cd inadyn
3. Download the program from ftp://troglobit.com/inadyn/
and decompress it
4. Go to the directory
5. Compile and install
make install
6. Create the confing file
with the following content
--password PASSWORD
--update_period 3600
--forced_update_period 14400
--alias HOSTNAME,alphanumeric key
--background
--dyndns_system default@freedns.afraid.org
--syslog
The bold words are the ones you should change. Remember the alphanumeric key is the one you got from right click on the Direct Link.
7. Start the client. Create the service file.
8. Add the following content.
Description=inadyn Dynamic DNS Update Client
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/sbin/inadyn
[Install]
WantedBy=multi-user.target
9. Start the service
and enable the service
10. Reboot and check if the service is running.
you should get results something like:
no-ip and openSUSE Raspberry Pi
Next step is to be sure that we can have access from outside our house (since most of the times, Raspberry Pi is located at home).
To do that we use Dynamic DNS services. A free service (so far) is No-IP. Most of the routers support it. You can use your router's service. But what if you want 2 different host names on the same IP? Let's say you have different ARM boards on the same router or you have a server etc.
1. First of all, install the needed programs to build the service (same as I did with ZNC)
2. Then
cd noip
3. Download the program
and decompress it
4. Go to the directory
5. Compile and install
make install
While it install’s the software you will prompted to enter the username & password. Once that is done it will ask you teh refresh interval … leave it.. to have the default value. You are required to answer some more questions … just ans NO an d you should be good to go.
6. Start the client
To check if the service is running, use the command:
and the results should be like
Process 1516, started as noip2, (version 2.1.9)
Using configuration from /usr/local/etc/no-ip2.conf
Last IP Address set EXTERNAL IP
Account USERNAME
configured for:
host HOSTNAME
Updating every 30 minutes via /dev/eth0 with NAT enabled.
Auto start the client on reboot
But what if you reboot? You want to start the client everytime you reboot. This can be done with systemd.
1. Create the service file.
2. Add the following content.
Description=No-IP Dynamic DNS Update Client
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/bin/noip2
[Install]
WantedBy=multi-user.target
3. Start the service
and enable the service
Create an openSUSE SD card for your Raspberry Pi B and B+
Here we'll see how to create an SD card with openSUSE. There are plenty of information at the wiki page https://en.opensuse.org/HCL:Raspberry_Pi
. I'll collect the information I need for projects I'll write next.
I used 13.1 as distro because it's easier for me to resize the SD card.
1. Download the image (openSUSE-13.1-ARM-JeOS-raspberrypi.armv7l.raw.xz) from here:
http://download.opensuse.org/repositories/devel:/ARM:/13.1:/Contrib:/RaspberryPi/images/
decompress the image.
2. Find the device name of your card
usually it's going to be /dev/mmcblk0.
and create the card (as root)
3. Since I didn't use a monitor (HDMI or DVI), I had to do some extra steps before boot my raspberry pi.
a. Delete the file /var/lib/YaST2/reconfig_system to start headless.
b. Resize the ext4 partition with Gparted.
4. When boot the Raspberry Pi, use the following
ssh root@IP
password: linux
Now the first command will be
and then update
Per service ulimits
In the good old days of sysvinit, if you wanted to run some extra code during start up, you were either (ab)using the sysconfig file or patching the init script itself. The init scripts in many packages are not as marked as configuration, which means in those cases your edits were lost. If it was marked as configuration then you have to merge your changes with those fixes manually. In either case … not ideal.
Apparmor and multiple instances of the same service
Getting started
Let’s say you want to have 3 instances of redis. One for each redis using app. Getting 3 instances app with systemd’s nifty Instantiated Services is easy.
[Unit]
Description=Redis
After=network.target
PartOf=redis.target
[Service]
Type=simple
User=redis
Group=redis
PrivateTmp=true
PIDFile=/var/run/redis/%i.pid
ExecStart=/usr/sbin/redis-server /etc/redis/%i.conf
Restart=on-failure
[Install]
WantedBy=multi-user.target redis.target
“systemctl start redis@discourse” will launch us an instance with “discourse.conf”. Other systemctl commands just work as fine. “systemctl enable redis@discourse” , “systemctl status redis@discourse” . Now to stop all redis instances? “systemctl stop redis.target”
Deploying Docker for OpenStack with Crowbar
A couple of months ago, I was meeting colleagues of mine working on Docker and discussing about how much effort it would be to add support for it to SUSE OpenStack Cloud. It's been something that had been requested for a long time by quite a number of people and we never really had time to look into it. To find out how difficult it would be, I started looking at it on the evening; the README confirmed it shouldn't be too hard. But of course, we use Crowbar as our deployment framework, and the manual way of setting it up is not really something we'd want to recommend. Now would it be "not too hard" or just "easy"? There was only way to know that... And guess what happened next?
It took a couple of hours (and two patches) to get this working, including the time for packaging the missing dependencies and for testing. That's one of the nice things we benefit from using Crowbar: adding new features like this is relatively straight-forward, and so we can enable people to deploy a full cloud with all of these nice small features, without requiring them to learn about all the technologies and how to deploy them. Of course this was just a first pass (using the Juno code, btw).
Fast-forward a bit, and we decided to integrate this work. Since it was not a simple proof of concept anymore, we went ahead with some more serious testing. This resulted in us backporting patches for the Juno branch, but also making Nova behave a bit better since it wasn't aware of Docker as an hypervisor. This last point is a major problem if people want to use Docker as well as KVM, Xen, VMware or Hyper-V — the multi-hypervisor support is something that really matters to us, and this issue was actually the first one that got reported to us ;-) To validate all our work, we of course asked tempest to help us and the results are pretty good (we still have some failures, but they're related to missing features like volume support).
All in all, the integration went really smoothly :-)
Oh, I forgot to mention: there's also a docker plugin for heat. It's now available with our heat packages now in the Build Service as openstack-heat-plugin-heat_docker (Kilo, Juno); I haven't played with it yet, but this post should be a good start for anyone who's curious about this plugin.
Developing developers: From end-user to developer
Building a Community
Building a community can be challenging, but we've learned a few things from our experience in Greece. Here’s a quick guide based on what worked for us.
People Over Products
While a cool product is great (no matter which one), it’s the people who truly matter. It’s crucial to help potential volunteers understand why they should join a community. Is it because they want to support FLOSS to make the world a better place? Because it’s fun? Because they value the benefits of open source? Or because they simply enjoy helping others? Understanding the motivations behind joining or forming a community is key to sustaining it.
Growing Your Community: Attend Events
One of the most effective ways to grow your community is to attend events. The ideal scenario would be a developer visiting your booth and immediately deciding to join the team. Unfortunately, that’s highly unlikely—maybe a 1% chance (or even less). Most developers already have their favorite distribution or project and are not easily swayed.
Instead, target events where you can meet end users. These are usually computer science students who primarily use Windows or everyday users whose computers are mainly for social media or office tasks. Why focus on them? Because they can take on tasks that developers often avoid—tasks like:
- Junior Jobs List: Create a list of simple, well-defined tasks that newcomers can easily pick up.
- Bug Reporting: Encourage users to report bugs through platforms like Bugzilla, while developers respond politely and guide users on how to provide relevant information.
- Documentation: Developers often dislike writing documentation. End users can fill this gap by documenting how to use and troubleshoot the software.
- Translation: Encourage volunteers to make content accessible and clear, especially when developers use technical language.
- Promotion and Engagement: Focus on community engagement rather than traditional marketing. Spread the word and build awareness because even the best project is useless if no one knows about it.
Building a Supportive Environment
People join communities not just because of the product but because of the people within the community. Once they’re part of it, they stay because they feel welcome and valued.
Managing volunteers can be tricky since there’s no hierarchy to enforce tasks. If someone takes credit for the community's efforts or doesn’t acknowledge the contributions of others, it can drive members away and ultimately dissolve the community.
Keeping the Community Alive
The reality is that you can’t keep a community together indefinitely. Even in the best-case scenario, people grow and evolve. Their available time becomes limited as personal life and careers take priority. The best way to sustain the community is to continually onboard new people before the core members inevitably move on.
From End User to Developer
Transitioning from an end user to a developer is the natural progression for community members who become deeply involved. It’s nearly impossible for an existing developer from, say, Fedora to suddenly switch to developing exclusively for openSUSE. Instead, communities should focus on nurturing new developers from within.
Start by engaging end users with simple tasks. As they grow more curious, they’ll gradually take on more challenging roles—like fixing bugs or learning to package software. Eventually, they become developers themselves. Even if they stop promoting the project, the community has gained a new developer—a net positive.
Final Thoughts
Developing developers is crucial for long-term sustainability. Help end users grow by providing guidance and opportunities to learn. In the end, a thriving community is one that continually supports its members in their journey from end user to developer.