User Tools

Site Tools


haas:status:status_201406

STATUS updates

TODO

  • the formular plugin is giving me errors, need to figure this out (email assignment form)
  • update grade not-z scripts to handle/be aware of winter terms
  • update system page for (new)www
  • redo DSLAB tweedledee/tweedledum with squeeze rebuilt tweedledee, tweedledum on the way
    • rebuild DSLAB www, irc, auth as squeeze VMs
  • load balance/replicate www/wiki content between LAIR and DSLAB
  • adapt LAIR irc and lab46 to use self-contained kernels (how to do this?)
  • update system page for db
  • migrate nfs1/nfs2 system page to current wiki
  • update nfs1/nfs2 to squeeze
  • flake* multiseat page

URLs

Some links of interest:

Other Days

April 15th, 2014

locale issues on utilite

Being a fresh install, I have encountered an old problem anew… and apparently due to a lack of documentation on my part, I now no longer know how to adequately fix it.

First of all, WHAT:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_TIME = "en",
	LC_MONETARY = "en",
	LC_COLLATE = "C",
	LC_ADDRESS = "en",
	LC_TELEPHONE = "en",
	LC_NAME = "en",
	LC_MEASUREMENT = "en",
	LC_IDENTIFICATION = "en",
	LC_NUMERIC = "en",
	LC_PAPER = "en",
	LANG = "en_US"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

I found what SHOULD be a fix here:

It describes:

  • locale-gen en_US en_US.UTF-8
  • dpkg-reconfigure locales

/etc/environment

I also modified /etc/environment by appending the following lines:

LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8

We'll see if it works.

URL: http://ubuntuforums.org/showthread.php?t=1720356

GNOME hacking: Getting my Volume Control back

As I was setting up the Utilite with LDAP and their non-default 'utilite' user, my volume control in the GNOME panel went away. I was able to get sound back with appropriate membership to local system groups (reference specific assignments of wedge in /etc/group), but volume adjustment wasn't available.

To fix (manually), run: gnome-sound-applet

To fix (automatically), run: gnome-session-properties and add an entry.

URLs:

April 16th, 2014

grep broken (revisited)

The locale settings on the utilite have caused a return of some problems experienced long ago, where grep appears to break.

Interestingly, fixing them on the utilite caused things to break on lab46.

The new fix? Setting LC_ALL equal to C restores the desired functionality.

I'll have to implement these fixes to lair-std

URL: https://bugzilla.redhat.com/show_bug.cgi?id=826997

June 4th, 2014

attempted botnet penetration

It appears that, sometime around midnight on June 2nd, a lab46 user account was accessed and a wordpress exploiting botnet vulnerability was attempted to deploy. Fortunately, we neither run wordpress, nor was the user in possession of any privileges causing any sort of invalid access (heck, with lab46 not even running a web server, we were insulated on that front too).

I only discovered it due to abnormally high load generated by a user who has not been on in some time. Account locked, files deleted… issue appears resolved (for now).

moar info

Seems the initial “break in” was May 12th/May 13th…. what seems to be an actual ssh login from 109-186-3-14.bb.netvision.net.il; yet no obvious brute force seems visible.

Did the two impacted users leave their passwords somewhere visible? Like a wiki entry?

Not that I can see. So I am unsure how they were compromised. So far it looks like it was just those two users.

URLs:

upgrading wiki

An update to dokuwiki came out a month ago… I dropped in the upgrade… seemingly seamless… looking for any hiccups. As of yet it seems like one of the smoother upgrades.

June 9th, 2014

sftp logging

One of the mysteries surrounding the recently discovered breach is still “how?”… knowing the bulk of activity came in via scp/sftp, I figured it might be a good idea if such accesses were logged. Well, now we are (as configured in the sshd config file):

Subsystem       sftp    /usr/libexec/openssh/sftp-server -l INFO

No further instances of illicit accesses… but then again, it doesn't look like we were specifically targeted, but instead one of many machines being hit possibly via some scripted effort (still no less disconcerting).

June 18th, 2014

ceph url

haas/status/status_201406.txt · Last modified: 2014/07/01 01:12 by 127.0.0.1