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?
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.
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
@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.
Could you please link me the instructions you are trying to follow?
@telphan, I have given it in the above discussion
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?
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.
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.confin the/system-proxydirectory on theresin-bootpartition of the downloaded image for provisioning the device - Ensure the
redsocks.confincludes the lines:daemon = offlocal_port = 12345
- Fill in the rest of the
redsocks.confwith 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.
Hi @hedley, thanks for the response 
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
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:
- 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:
We want to use the boot partition, which is where theDevice 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 Linuxsystem-connectionsdirectory exists. - Create a new mount partition, we’ll call it
/mnt/resin:
sudo mkdir /mnt/resin - 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 - You should now be able to list the boot partition:
As you can see, thels /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-connectionssystem-connectionsdirectory is now present. - Make relevant changes, creating a
redsocks.conffile:
sudo emacs /mnt/resin/system-connections/redsocks.conf - 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!
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?
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.
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?
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.
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.
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.
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.
@Manoj, yes, you’re right about the change.
If that doesn’t work, switching to a .dev image would help us debug further.
@pcarranzav @hedley
Hey, is there any directory named system-proxy in the boot-partition?
There are only 3 directories EFA,splash,system-connections