Forgot your password?

Comment: Systemd seems fine to me at this stage (Score 3, Interesting) 522

by rongten (#48170569) Attached to: Debian Talks About Systemd Once Again


  I have deployed some fedora 20 machines in the last 3-4 months, and so far I did not see anything that led me to cry foul against systemd.

  Actually, the handling of the user sessions for house-keeping purposes seems much simpler now.

  So I don't get all this hate. Maybe I did not look deep enough, time will tell.


Comment: Re:Fleeing abusive companies? (Score 1) 257

by rongten (#47735127) Attached to: When Customer Dissatisfaction Is a Tech Business Model

Here in Belgium a registered snail mail is sufficient in general to cancel a service (i.e. cable).
Last time I changed internet provider I waited the expiration of the contract, but I think now they have more consumer friendly laws and you can change with much more ease.

The general idea is to foster competition between companies making it easier for a customer jumping ship and woting with his wallet/her purse.

Of course other governamental intervention (forcing the old telecom monopoly to lease their infrastructure at reasonable price and now trying to do the same for cable) is a godsent.

You can always argue that the incumbent has the advantage (because you may want to avoid the ping pong between the virtual operator and the incumbent), but sure as hell it looks infinitely better of what people have suffering in USA.

I got friends going to work there and being flabbergasted by the internet connections and prices...

Comment: Re:Good grief (Score 1) 98

by rongten (#47511059) Attached to: Ask Slashdot: Linux Login and Resource Management In a Computer Lab?

Exactly the last point.

  What I dislike the most are users that take advantage of others due to their lack of knowledge. And this is either done intentionally or unintentionally when rules are not enforced.

I would like all the students (often coming in contact with linux, shell programming and clusters for the first time) to have a fair shot of using the available resources, and not to backstab each other.

  Before everyone could run on the cluster, until I discovered that certain students were giving their login to others: the first did not really need it (i.e. theoretical work) and the second would run on the cluster twice the amount of jobs of the others.

Comment: Re:Just deal with problem users individually. (Score 1) 98

by rongten (#47510961) Attached to: Ask Slashdot: Linux Login and Resource Management In a Computer Lab?


  the beowulf clusters we have are running either based on Centos or SLES. For the development workstations where newer versions of certain software are needed I install Fedora.

  This means the developers basically run production on the cluster and develop on the workstations.

  Since there is always a gap between the two (i.e. centos 5 on cluster and fedora 16 on workstations before, centos 6 on cluster and fedora 20 on workstation), when the cluster is updated there is limited breakage, at least until now.

  I understand those that push a stable distro everywhere, maybe for next cycle I will do the same, who knows.

+ - Ask Slashdot: Linux Login and Resource Management/Restriction in a Computer Lab

Submitted by rongten
rongten (756490) writes "I am managing a computer lab composed of various kind of Linux workstations, from small desktops to powerful workstations with plenty of ram and cores. The users' $HOME is NFS mounted, and they either access via console (no user switch allowed), ssh or x2go. In the past the powerful workstations were reseved to certain power users, but now even "regular" students may need to have access to high memory machines for some tasks.
I ask slashdort, is there a sort of resource management that would permit: to forbid a same user to log graphically more than once (like UserLock), to limit the amount of ssh sessions (i.e. no user using distcc and spamming the rest of the machines or even worse running in parallel), to give priority to the console user (i.e. automatically renicing remote users jobs and restricting their memory usage), to avoid swapping and waiting (i.e. all the users trying to log into the latest and greatest machine, so have a limited amount of logins proportional to the capacity of the machine).
The system being put in place uses Fedora 20, ldap PAM authentication, it is puppet managed, and NFS based. In the past I tried to achieve similar functionality via cron jobs, login scripts, ssh and nx management, queuing system.
But it is not an elegant solution and it is hacked a lot.
Since I think these requirements should be pretty standard for a computer lab, I am surprised to see that I cannot find something already written for it.
Does any of you know of a similar system, preferably opensource? A commercial solution could be acceptable as well."

No man is an island if he's on at least one mailing list.