Resin on VirtualBox


#1

I tried running the above steps but my dashboard does not show any devices connected. What could be the reasons for not having this connection? I even tried changing network types but I was in vain. Does it have anything to do with the virtualbox version?


#3

Hi @Manoj

Can you clarify the steps you have completed and the state of your current environment so I am able to help further.

Thanks.


#4

Hi @wrboyce
I first made an account on resin.io
Named an application with device type "Intel NUC"
Downloaded ResinOS image and converted it from .img (2.3 GB file) to .vmdk (~570 MB file)
Started a Virtual Machine on VirtualBox. Did not add a virtual disk image in the start.
Disabled to I/O APIC and enabled EFI.
Added SATA controller, initially added a .vdi disk and uploaded a second disk (the .vmdk file)
Kept the network settings as it is (NAT).
Ran the VM. Got a Boot screen and the host OS was being installed, but nothing showed up on the dashboard.
VM got shut down itself. Removed the .vmdk file and again started the VM. The device did not show up on the dashboard.
Kept changing the network types. Did not show any effect


#5

@wrboyce
Regarding the current environment, I am working on Windows 7 desktop. I am working from the office building and the company uses proxy servers here.


#6

Could you please link me the instructions you are trying to follow?


#7

@telphan, I have given it in the above discussion


#8

Hi @telphan and @wrboyce
I tried resin on virtualbox from my home network and it works fine. How could I get it to work fine from network running proxy servers?


#9

@wrboyce @telphan

We are trying to setup Resin client in office environment, due to controlled network environment we are not able to connect to the cloud.
We are exploring possibility if we can setup resin server locally and complete testing.
Please let us know how to do that.


#10

Hi @Manoj,

It’s not possible to run the resin.io service as a local instance. However, if you are using proxy servers within your network environment, you should be able to use these in the Virtual device. There’s more details in this post, but essentially:

  • Create a redsocks.conf in the /system-proxy directory on the resin-boot partition of the downloaded image for provisioning the device
  • Ensure the redsocks.conf includes the lines:
    • daemon = off
    • local_port = 12345
  • Fill in the rest of the redsocks.conf with the proxy settings for the network

This should allow the virtual device to connect to the resin.io servers. Note also that this works only with device images that use the NetworkManager component to configure them, but as you’re provisioning a new device, this should be the case anyway.


#11

Hi @hedley, thanks for the response :slight_smile:
But, there is one problem which I would like to understand. To get to the /system-proxy directory, I need to access the device files. To access the files, I need to get it connected to the network and have the dashboards showing my running device. If I am unable to connect to the network, how will I access the files?

Since I am using the device as a virtualbox, I cannot use the web-terminal for accessing it. But accessing to web terminal only comes into picture when I connect it to the network and is running


#12

Hi @Manoj,

You should be able to change the files in the downloaded image before you use it to set up your virtual device.

This can be achieved by mounting the first (boot) partition of the downloaded Resin image and modifying the files directly within it.

For example, under Linux this can be achieved in the following way:

  1. Determine the offset for the boot image. Assuming the downloaded Resin image was called resin.img, run:
    fdisk -l resin.img
    This will give you a list including the following:
     Device Boot      Start         End      Blocks   Id  System
    resin.img1   *        8192       90111       40960    e  W95 FAT16 (LBA)
    resin.img2           90112      729087      319488   83  Linux
    resin.img3          729088     1368063      319488   83  Linux
    resin.img4         1368064     3522559     1077248    f  W95 Ext'd (LBA)
    resin.img5         1376256     1417215       20480   83  Linux
    resin.img6         1425408     3522559     1048576   83  Linux
    
    We want to use the boot partition, which is where the system-connections directory exists.
  2. Create a new mount partition, we’ll call it /mnt/resin:
    sudo mkdir /mnt/resin
  3. Mount the boot partition in local loopback using the mount partition, using the offset of the boot parition (in the above case 8192):
    sudo mount -t vfat -o rw,loop,offset=$(( 8192 * 512 )) resin.img /mnt/resinimage
  4. You should now be able to list the boot partition:
    ls /mnt/resin
    bcm2708-rpi-0-w.dtb     bcm2709-rpi-2-b.dtb               bootcode.bin  device-type.json  fixup_x.dat         resin-image          start_db.elf
    bcm2708-rpi-b.dtb       bcm2710-rpi-3-b.dtb               cmdline.txt   fixup_cd.dat      image-version-info  resinos.fingerprint  start.elf
    bcm2708-rpi-b-plus.dtb  bcm2710-rpi-cm3.dtb               config.json   fixup.dat         kernel7.img         splash               start_x.elfec
    bcm2708-rpi-cm.dtb      bcm2835-bootfiles-20170405.stamp  config.txt    fixup_db.dat      overlays            start_cd.elf         system-connections
    
    As you can see, the system-connections directory is now present.
  5. Make relevant changes, creating a redsocks.conf file:
    sudo emacs /mnt/resin/system-connections/redsocks.conf
  6. When you’ve finished filling it in, sync and then unmount the partition:
    sync; sudo umount /mnt/resin

You can now use your image to provision the virtual device (the NUC) in the usual fashion and the proxy will kick in.

Hope this helps!


#13

Thank you @hedley.
But, the problem here is that the environment in which I am working is on windows 2007. How can I achieve on this OS?


#14

Hi @Manoj,

Unfortunately I don’t work under Windows, so do not have first hand knowledge.

However, a quick search has yielded a few different potential utilities:

https://www.osforensics.com/tools/mount-disk-images.html
http://wincdemu.sysprogs.org/
http://www.magiciso.com/tutorials/miso-magicdisc-history.htm

These all look like they can work with .img files, which should allow you to mount and read/write the boot partition.


#15

Hi @hedley,
Thank you for the description on how to change the configurations to run the image on proxy. Though the changes have been made as described, the device still doesn’t show on dashboard. I made ‘daemon=off’ and ‘local_port=12345’. \

I doubt regarding the ip and port settings. Should I leave it as it is or should I change it? If I should change it, whose ip and port settings are to be entered?


#16

Hi @Manoj,

Just to check, does the rest of the redsocks.conf file match the proxy settings required for your internal proxy? Would it be possible for you to post the entire config here so we can have a look at it?

Thanks.


#17

Hi @hedley,
The proxy is proxy.**** .com and port is 80***

The following is the config file:

base {
// debug: connection progress
log_debug = off;

// info: start and end of client session
log_info = on;

/* possible `log' values are:
 *   stderr
 *   "file:/path/to/file"
 *   syslog:FACILITY  facility is any of "daemon", "local0"..."local7"
 */
log = stderr;
// log = "file:/path/to/file";
// log = "syslog:local7";

// detach from console
daemon = off;

/* Change uid, gid and root directory, these options require root
 * privilegies on startup.
 * Note, your chroot may requre /etc/localtime if you write log to syslog.
 * Log is opened before chroot & uid changing.
 * Debian, Ubuntu and some other distributions use `nogroup` instead of
 * `nobody`, so change it according to your system if you want redsocks
 * to drop root privileges.
 */
// user = nobody;
// group = nobody;
// chroot = "/var/chroot";

/* possible `redirector' values are:
 *   iptables   - for Linux
 *   ipf        - for FreeBSD
 *   pf         - for OpenBSD
 *   generic    - some generic redirector that MAY work
 */
redirector = iptables;

/* Override per-socket values for TCP_KEEPIDLE, TCP_KEEPCNT,
 * and TCP_KEEPINTVL. see man 7 tcp for details.
 * `redsocks' relies on SO_KEEPALIVE option heavily. */
//tcp_keepalive_time = 0;
//tcp_keepalive_probes = 0;
//tcp_keepalive_intvl = 0;

// Every `redsocks` connection needs two file descriptors for sockets.
// If `splice` is enabled, it also needs four file descriptors for
// pipes.  `redudp` is not accounted at the moment.  When max number of
// connection is reached, redsocks tries to close idle connections. If
// there are no idle connections, it stops accept()'ing new
// connections, although kernel continues to fill listenq.

// Set maximum number of open file descriptors (also known as `ulimit -n`).
//  0 -- do not modify startup limit (default)
// rlimit_nofile = 0;

// Set maximum number of served connections. Default is to deduce safe
// limit from `splice` setting and RLIMIT_NOFILE.
// redsocks_conn_max = 0;

// Close connections idle for N seconds when/if connection count
// limit is hit.
//  0 -- do not close idle connections
//  7440 -- 2 hours 4 minutes, see RFC 5382 (default)
// connpres_idle_timeout = 7440;

// `max_accept_backoff` is a delay in milliseconds to retry `accept()`
// after failure (e.g. due to lack of file descriptors). It's just a
// safety net for misconfigured `redsocks_conn_max`, you should tune
// redsocks_conn_max if accept backoff happens.
// max_accept_backoff = 60000;

}

redsocks {
/* local_ip' defaults to 127.0.0.1 for security reasons, * use 0.0.0.0 if you want to listen on every interface. *local_*’ are used as port to redirect to.
*/
local_ip = 127.0.0.1;
local_port = 12345;

// listen() queue length. Default value is SOMAXCONN and it should be
// good enough for most of us.
// listenq = 128; // SOMAXCONN equals 128 on my Linux box.

// Enable or disable faster data pump based on splice(2) syscall.
// Default value depends on your kernel version, true for 2.6.27.13+
// splice = false;

// `ip' and `port' are IP and tcp-port of proxy-server
// You can also use hostname instead of IP, only one (random)
// address of multihomed host will be used.
ip = proxy.**** .com;
port = 80**** ;

// known types: socks4, socks5, http-connect, http-relay
type = socks5;

// login = "foobar";
// password = "baz";

// known ways to disclose client IP to the proxy:
//  false -- disclose nothing
// http-connect supports:
//  X-Forwarded-For  -- X-Forwarded-For: IP
//  Forwarded_ip     -- Forwarded: for=IP # see RFC7239
//  Forwarded_ipport -- Forwarded: for="IP:port" # see RFC7239
// disclose_src = false;

// various ways to handle proxy failure
//  close -- just close connection (default)
//  forward_http_err -- forward HTTP error page from proxy as-is
// on_proxy_fail = close;

}

Could you please look at it.


#18

Hi @Manoj! In what directory did you put the redsocks.conf file?
(There was some confusion in @hedley’s messages above, the correct directory is system-proxy in the resin-boot partition)

Otherwise your configuration looks fine to me. Are you using a development OS image? If so, could you ssh into the virtual device and send us the output of systemctl status resin-proxy-config and systemctl status redsocks? That would help diagnose what’s going on. It will also validate that the virtual machine is configured in a way that allows network connectivity.


#19

Hi @pcarranzav!
If the correct directory is system-proxy, then the command
sudo emacs /mnt/resin/system-connections/redsocks.conf
should change to
sudo emacs /mnt/resin/system-proxy/redsocks.conf
Am I right?
I am using v2.2.0+rev1.prod image as it was given as recommended.


#20

@Manoj, yes, you’re right about the change.

If that doesn’t work, switching to a .dev image would help us debug further.


#21

@pcarranzav @hedley
Hey, is there any directory named system-proxy in the boot-partition?
There are only 3 directories EFA,splash,system-connections