Use a device over SSH?

Question

I am in the process of adding some AspectJ advices in my Spring-based Java project. When I run an intercepted method once, it all works fine (i.e., the advice is executed). However, the next invocation of the very same method does not go through the proxy anymore.

This is my test code:

@Test
public void testFooOperationIsAdviced() throws Exception {
    TestController testController = appContext.getBean("testController");
    testController.foo();
    testController.foo();
}

Here's the foo() method:

@Protect()
public void foo() {
    System.err.println("foo!")
}

And this is the relevant part in my Spring configuration:

<aop:aspectj-autoproxy />
<bean name="myAdvice" class="mypackage.MyAdvice"/>

<bean id="testController" class="mypackage.MyTestControllerImpl" />

<aop:config>
    <aop:aspect id="protectAspect" ref="myAdvice">
        <aop:pointcut id="annotatedController" expression="execution(public * mypackage.*+.*(..)) and @annotation(protect)" />
        <aop:around pointcut-ref="annotatedController" method="applyProtectionRules" arg-names="protect"/>
    </aop:aspect>
</aop:config>

The aspect is currently just doing System.err.println("advice") and pp.proceed().

So, if we execute the test above, you'd expect

advice foo! advice foo!

However, what I get is:

advice foo!

The second invocation never gets to the advice! And, what is worse, the target method is not even executed.

Do you have any clue as to why this happens?

Note 1: To make things worse: sometimes, when I execute with the debugger and go step by step, it does work normally. No kidding...

Note 2: If there are typos in the config, they are just typos, since I adapted the original code to make it simpler. Take into account that the aspect does work for the first invocation.

Note 3: I do want to stick to Spring. I can't have the pointcuts hardcoded in the Java code, since I want the library user to provide their own, and the only way I can think of is let them define the aop:config block.

Solution 1

SSHFS does not work that way -- it handles files, but not devices. Everything is a file, but there are many types of files, including: regular files, directories, symbolic links, sockets, character devices, and block devices.

% ls -l /dev/sda
brw-r----- 1 root disk 8, 0 Oct  9 20:59 /dev/sda

The letter b indicates this is a block device. These types of files support ioctl in addition to the normal read and write functions. The purpose of ioctl is to allow a way to do "extra" operations to the device. These operations are different for each type of device: a DVD device can open/close its door, but an ethernet device cannot.

This is why the SSHFS software cannot make device files available over the network.

You will need a different system that is made for this purpose, something like webCDwriter.

Solution 2

If you want to remotely access a block device, there is such a tool called 'nbd' (Network Block Device). I have used this in the past to clone a harddrive using dd if=/dev/nbd0 of=/dev/hda with reasonable success.

However, I doubt this will work for optical drives.

I think you'd be better off running the burning software locally on the remote machine (say with X or VNC), and have it pull files using regular file sharing mechanisms like samba or NFS.

Solution 3

Linux/UNIX are not Plan 9. "Everything is a file" doesn't mean that they're all the same sort of files. FIFOs and device nodes being prime examples.

No, you cannot do it this way. My recommendation would be to use a virtual writer (celebron writes to an image, .iso or other) and pipe that to cdrecord over ssh.

Solution 4

Brasero and K3b don't see a DVD device because your local computer's OS kernel doesn't see a DVD device.

Mounting filesystems remotely is easy; there are network protocols like CIFS, NFS, AFS, and even SSHFS to handle all the details of file access. But low-level device access is a different animal -- note that none of these protocols would allow, for example, repartitioning or reformatting the filesystem being accessed.

You would need a low-level protocol like iSCSI, FCoE (Fibre Channel over Ethernet), or ATAoE (ATA over Ethernet) to do what you want to do. This would involve driver-level software on the remote device to export the device, and driver-level software on the local device to attach to it. There's Windows software called Starport that claims this capability, and a Linux-iSCSI site that may give you more information about what's currently possible.

But generally, these technologies are used in corporate data centers with expensive hardware. For general home use, you really want to run Brasero on your remote computer and just display the GUI window on your local system (via X, VNC, or some other remote desktop technology).

View more solutions

Comments

[Angel O'Sphere]

Can it be that the first call to testController.foo(); causes an exception?

[espinchi]

No, it's not that (as you can see in the accepted answer), but it was a good guess, thanks!

[Zaz]

SSHFS cannot handle block devices. Look into Network Block Device if this is something you really need.

[phresus]

AFAIK, iSCSI will not send ATAPI commands. Remote X, FreeNX, VNC are great sugggestions.

[DrColossos]

I never tried it -- if it sucks, don't blame me :D

[espinchi]

In two days, SO will allow me to accept this answer as the solution.

[Simone Gianni]

It happens, thanks for posting the solution and admitting the error.