switch to room list switch to menu My folders
Go to page: First ... 119 120 121 122 [123] 124 125
[#] Wed Aug 23 2017 12:05:45 EDT from Ragnar Danneskjold @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I'd have more problems with OSX if it weren't geared towards the desktop....
It's pretty rare you need to get that deep into the system.

[#] Fri Aug 25 2017 20:07:19 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

2017-08-18 11:22 from LoanShark @uncnsrd

Back on that topic, I think I solved my systemd problem. Basically,
systemd thinks it knows whether your service is running or not; it can

be wrong. If your service was invoked directly from the init script, it

doesn't know it's running when it is; if the start script fails,
systemd will think it's running when it isn't; if the stop script
fails, it may think it's not running when it is. Etc. In either of
those states, the "stop" or "start" command may do nothing at all, by

itself, because systemd thinks there's no state transition that needs

to happen.

It's all a bit boneheaded, but there are ways to deal with it.

PIDFile=[path to your PID file]

If your service creates a PID file, systemd will use the file specified by PIDFile to track whether or not the service is actually running, rather than trying to chase forks in a daemonizing process.

So, if your service can be told to create a PID file, that should help significantly.

If not... well, I dunno how you dealt with it in sysvinit.

[#] Sat Aug 26 2017 19:06:12 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

And that's why I'd love it if systemd became universal, at least for Linux ... instead of all the tedious mucking about with pid files, you could just run the program without forking into the background, systemd will spawn the process directly and can respond to it exiting.

[#] Sun Aug 27 2017 23:22:45 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It's universal enough though, right? It's now the default on both Ubuntu and RedHat-derived systems.

[#] Mon Aug 28 2017 12:13:27 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Honestly, if I didn't have to deal with older distributions, I'd stop doing the whole daemonization thing and just run it as you might run any command on a command line.

Hrm... although, honestly, I could do both. I could take a command line argument that would daemonize if needed...

[#] Mon Aug 28 2017 13:34:59 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It's universal enough though, right? It's now the default on both
Ubuntu and RedHat-derived systems.

Hmm. According to it has been the default on CentOS, Debian, Fedora, Mint, SuSE, Red Hat, and Ubuntu for some time now (plus some others that I'm not counting as anything other than fringe players).

The question of course is: "as a software distributor, should I write exclusively to systemd?" I'm starting to think the answer is "yes" because anyone still running sysvinit in 2017 is probably already dealing with being a fringe player.

[#] Wed Aug 30 2017 10:54:47 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Heh... well, I'm having to deal with ancient distributions, so I still have to write for sysvinit, upstart, and pretty much anything else.

Detecting which init tool the distribution uses is a new kind of entertainment.
In the sense that amputation of major limbs is entertaining.

[#] Thu Aug 31 2017 14:30:48 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Right, and that's supposedly why every init-replacement at least *tries* to support sysvinit scripts. But it still feels sort of emulated and second-class.

[#] Wed Sep 06 2017 12:23:41 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I figured one had to support sysvinit for backwards compatibility.

I could have taken the easy approach, and just written sysvinit scripts and said 'screw it'. But... I really do want our software to start more dynamically than sysvinit might permit.

[#] Mon Sep 11 2017 14:29:22 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

For those who haven't seen it or tried it yet...

[ ]

Guacamole is an access server that requires nothing but a web browser to connect to the RDP, VNC, SSH, Telnet sessions of your choice. One might expect this to be slow and clunky, but it's actually *really* good. It's more responsive than even some non-browser-based clients.

I'm using it now, in fact :)

[#] Fri Sep 15 2017 06:41:18 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That's intriguing.

I wonder how well that works within a virtualized environment. Hmm...

[#] Fri Sep 15 2017 10:17:06 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That's how I'm running it. The underlying Linux machine is even joined to an Active Directory domain. If that doesn't make your head explode...

[#] Mon Sep 18 2017 12:16:29 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, that's the kind of blinkered, Philistine pig-ignorance I've come to expect from you non-creative garbage...

[#] Wed Sep 20 2017 09:44:17 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

All we wanted was a simple Linux server, not an abbatoir.

I've gotta say though, nslcd (aka nss-pam-ldapd) is freaking awesome. Joining a Linux machine to an Active Directory domain used to be a gigantic pain in the ass. Winbind was a piece of garbage, had too many dependencies, and had a habit of just not staying working. nslcd ties the name service switch directly to LDAP, no shims, no gimmicks. It also works with *any* LDAP server, not just AD.

When you have hundreds of servers it's nice to be able to log in with your LDAP credentials instead of having to go into the password vault to fetch the root password.

[#] Thu Sep 21 2017 12:12:03 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

How badly does it consume bandwidth, doyouknow?

I'd expect if it's using those underlying protocols, it's probably fairly trim.

Oh.... and I wonder if you can record it to an mp4 or something. That'd be super-useful.

[#] Thu Sep 21 2017 23:26:33 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I haven't looked at bandwidth consumption because the server I'm running it on has plenty of it. It is going to use its own protocol to the client browser plus whatever bandwidth is consumed from the Guac server to the server you're logging into.

I haven't tried using it from anywhere other than my own well-endowed home network yet. I'll report back next week when I'm sitting in an airport using a tethered phone and we'll see. I think it's still going to be pretty good.

And yes, there is a screen recording module available. :)

[#] Fri Sep 22 2017 06:19:51 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

For my needs, that screen recording thing, if I can route the recording to a server elsewhere, would be amazingly useful.

[#] Sun Sep 24 2017 14:41:33 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Read through [ ] and check out the section on "Session Recording."

[#] Wed Sep 27 2017 16:30:41 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I've set up a guacamole server/client that shows a proof of concept. It works very, very smoothly... far more smoothly than what we're doing at the moment through our vendor.

That, alone, makes me want to use this. Add to it recording features, and it's all the better... I may play with that tomorrow.

It's a tad frustrating, though, that I couldn't get the same familiar desktop in linux as the console's desktop (meaning, as if a CRT were connected to the VM, if that were possible). That's a bit of a shame, and might be a problem for certain distributions (Security Onion, Kali, etc). I dunno... maybe I can work around that somehow.

[#] Thu Sep 28 2017 10:51:57 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I got Linux graphical desktop via Guacamole working by using VNC. It takes a lot of manipulation, but you can combine VNC server with xinetd in a way that makes it fire up a new session and present a login prompt whenever someone connects to port 5900.

It would be easier if Guacamole could natively speak X11 and XDMCP. Although Guacamole has been designed to be extended in this way, no one has written this protocol yet.

Go to page: First ... 119 120 121 122 [123] 124 125