Tue, 30 Dec 2014
PF 2015
I wish a nice year 2015 to all readers of this blog.
0 replies for this story:
Reply to this story:
Sat, 20 Dec 2014
HDMI Sound
Another problem related to getting a new mainboard was sound. The mainboard has an on-board Intel GPU, which I use for the first seat. Unlike my previous graphics card for the Seat0, it is connected by HDMI port to my monitor. So I have decided to give sound over HDMI a try.
The problem was that it did not work: using pavucontrol, I have verified that sound is routed correctly to the HDMI interface, but the interface said that the output is disconnected. And I did not know how to "connect" it, because physically it has obviously been connected.
After some hours of searching I have found the following solution:
$ pactl list cards ... Card #1 Name: alsa_card.pci-0000_00_03.0 Driver: module-alsa-card.c Profiles: output:hdmi-stereo: Digital Stereo (HDMI) Output (sinks: 1, sources: 0, priority: 5400, available: yes) output:hdmi-surround: Digital Surround 5.1 (HDMI) Output (sinks: 1, sources: 0, priority: 300, available: yes) output:hdmi-stereo-extra1: Digital Stereo (HDMI 2) Output (sinks: 1, sources: 0, priority: 5200, available: yes) output:hdmi-surround-extra1: Digital Surround 5.1 (HDMI 2) Output (sinks: 1, sources: 0, priority: 100, available: yes) output:hdmi-stereo-extra2: Digital Stereo (HDMI 3) Output (sinks: 1, sources: 0, priority: 5200, available: yes) off: Off (sinks: 0, sources: 0, priority: 0, available: yes) Active Profile: output:hdmi-stereo Ports: hdmi-output-0: HDMI / DisplayPort (priority: 5900, latency offset: 0 usec, not available) Properties: device.icon_name = "video-display" Part of profile(s): output:hdmi-stereo, output:hdmi-surround hdmi-output-1: HDMI / DisplayPort 2 (priority: 5800, latency offset: 0 usec, not available) Properties: device.icon_name = "video-display" Part of profile(s): output:hdmi-stereo-extra1, output:hdmi-surround-extra1 hdmi-output-2: HDMI / DisplayPort 3 (priority: 5700, latency offset: 0 usec, available) Properties: device.icon_name = "video-display" device.product.name = "PLE2607WS" Part of profile(s): output:hdmi-stereo-extra2 $ pactl set-card-profile 1 output:hdmi-stereo-extra2
Apparently PulseAudio knows that the hdmi-stereo-extra2 is the only connected output, but remains set up to hdmi-stereo instead. Now that is not very user-friendly, plug&play, etc.
0 replies for this story:
Reply to this story:
Fri, 19 Dec 2014
Multiseat LightDM
After getting a new mainboard, I have upgraded my home computer to Fedora 20, and made my multiseat setup use the udev/logind/loginctl seat tags. About a month ago I have discovered that the seat numbers are not correctly assigned to sessions by xdm(8), so I started to look for solutions. Of course, that piece of crap called gdm was not even been considered for obvious reasons. Apparently the solution does exist, and suprisingly enough, it is really nice: it is called LightDM.
LightDM is the display manager. It has cleanly separated the display manager part (starting up the X servers, listening on XDMCP, etc.), and the user interface part (chooser). The later can be selected from various options - e.g. a KDE/Qt compatible one, and a GTK+ compatible one. The configuration is pretty straigthforward, and it does not try to hide anything from the user, unlike the above mentioned piece of crap.
The multiseat setup in LightDM is pretty straightforward: in /etc/ligthdm/lightdm.conf I have to add the following:
[Seat:0] xdg-seat=seat0 xserver-command=X -layout Primary -isolateDevice PCI:0:2:0 -seat seat0 vt7 [Seat:1] xdg-seat=seat1 xserver-command=X -layout Secondary -isolateDevice PCI:1:0:0 -seat seat1 -sharevts vt7
In the udev tags, I had to tag the following device as belonging to Seat1 (using loginctl(8)):
- The DRM device of the graphics card (.../drm/card1)
- The FB device of the graphics card (.../graphics/fb1)
- The sound card ports (.../sound/card1/inputXX)
- The USB port for the mouse (.../usb5/5-1)
- The USB port for the keyboard (.../usb5/5-2)
And that's it! The only (minor) nitpick is, that the GTK+ greeter does not remember the last logged-in user per seat, so it preselects the last logged in user on both seats by default. But we usually log in only after the reboot, so it is not a big problem.
0 replies for this story:
Reply to this story:
Tue, 16 Dec 2014
Systemd: ENOENT
I maintain a small software project (about 4k LOC) which is a part of the university infrastructure. It is versioned in Git and installed on several computers across the university. Today I wanted to deploy it on a Fedora 20 machine, which of course is running systemd.
Firstly about my position on systemd: I think most of the things they are trying to acchieve are pretty cool, but sometimes the implementation and design choices are a bit questionable. Anyway, I have written two unit files for my software, even with the unitname@.service wildcard syntax. The units are OK, systemctl start unitname-instance.service works as expected. The crash landing came when I wanted to enable these units after reboot:
# systemctl enable unitname-instance.service Failed to issue method call: No such file or directory
What's wrong with it? It can be systemctl start'd anyway, so the unit files should be OK, shouldn't they? After some hair pulling I have discovered that systemd intentionally ingores symlinks in the /usr/lib/systemd/system directory. Moreover, they just set O_NOFOLLOW and print whatever errno they get from the kernel, which is simply misleading. I think my use case - to have my own unit files in my git repository - is valid, and there is no reason for disallowing symlinked unit files.
Related Fedora bug reports: #1014311, #955379.
0 replies for this story:
Reply to this story:
Sat, 13 Dec 2014
CSIRTs Considered Harmful
OK, I am fed up with spam coming from local CSIRTs. Firstly from CSIRT MU, and recently even from the CESNET CSIRT.
"The Guild of Firefighters had been outlawed by the Patrician the previous year after many complaints. The point was that, if you bought a contract from the Guild, your house would be protected against fire. Unfortunately, the general Ankh-Morpork ethos quickly came to the fore and fire fighters would tend to go to prospective clients’ houses in groups, making loud comments like ‘Very inflammable looking place, this’ and ‘Probably go up like a firework with just one carelessly-dropped match, know what I mean?’"
-- Terry Pratchett: Guards! Guards!
This is the problem with Computer security incident response teams (CSIRTs). When they are to actually handle the security incident, they work well. However, security incidents are not very frequent, at least the important ones. So they tend to over-estimate the impact of many so-called security problems, and tend to keep people notified about their own existence by spamming them, or even demanding replies.
For example, CSIRT MU monitors the network traffic and sends notifications about "suspicious" traffic. The report is an e-mail with the URL where the details supposedly can be found. In that page, there is a partial description of the incident, with complete description available through another link. So instead of opening, reading and deleting a single e-mail, one has to read the e-mail, open the included URL, and follow the link in that page. For example, CSIRT MU sends us notifications about some computers in our network "scanning" foreign networks, even though it is clearly visible that the "attack" uses one source and one destination address, and lasts for only a few seconds. Which most probably means that someone ran nmap against his own remote machine. So CSIRT sends us their report using their ticket system, and even demands that we respond in time about the cause (each response gets sent back to us twice - once in Group reply, and the second time through their ticket system). After we explain what is probably going on, their response is not a polite "sorry for bothering you with false-positive, we will refine our detection criteria". The response is "OK, I am closing the ticket", and the next day they send us another false-positive.
A few days ago we've got another "incident report", this time from CESNET CSIRT. They were notifying us about a new HTTPS server in our network with the Poodlebleed vulnerability. OK, we have notified the server owner and got the response "we will eventually look at it, but the same content is available over plain HTTP, and it is only a testing server". Which is a perfectly valid response. But CESNET CSIRT thinks they should spam us every day until this so called "problem" gets fixed.
In my opinion, something like CSIRT with dedicated staff should not exist (except in the largest companies, may be). The security response people should be the regular staff doing their own work, designed to stop their regular work immediately, should the security incident emerge, and work on the security incident instead. But the dedicated staff has too much time in their hands, and tend to look for opportunities to let people know about their existence. The same way as Ankh-Morpork Firefighters Guild did.
5 replies for this story:
Vašek Stodůlka wrote:
You should create some serious incident for them to keep them busy for a while. :-)
bodik wrote: YES!!
this is very nice feedback and writing about something which I was thinking for some time now ... we'll definitely discuss this topic at the next wg meeting. thank you!
Yenya wrote: Re: bodik
Well, the real feedback (a polite one) has been sent in reply to that spam from CESNET CSIRT. So if you really want to help, look at that mail and think about whether it was OK to send out such a report.
bodik wrote: Re: Re: bodik
I'm not a handler nor regular administrator of that spamming device. I'm just a consultant for the team, so rising a broader discussion (beyond ticketing system) is the only thing I can do for now ...
Yenya wrote: Re: bodik
OK, thanks!
Reply to this story:
Wed, 10 Dec 2014
Apache Reload Bug
Yesterday I discovered something that I suspect to be a bug in Apache: we
use the same config file for many of our systems, and put the specific parts inside the <IfDefine> blocks.
When the Apache started, it worked as expected. However, after a graceful reload, it seems that some instances of Apache started interpreting some <IfDefine> blocks, even though the particular <IfDefine> string was not present in their command line.
I have even verified this by creating a dummy <IfDefine> block with a non-existent directive - the Apache server has started correctly, but died on a syntax error in the config file after a graceful reload.
Long story short, I have upgraded to the latest-greatest version of Apache, and the problem has disappeared. Has anybody seen something similar?
3 replies for this story:
Atrament wrote:
s/Yesterday I have discovered/I discovered/ Sorry to be a grammar Nazi but I noticed you misuse the present perfect very often. Present perfect (I have discovered) is to be used only when you speak about present, when you are talking about something what happened in the past, use the past simple (I discovered):)
Yenya wrote: Re: Atrament
OK, fixed. Thanks!
Atrament wrote:
s/Yesterday I have discovered/I discovered/ Sorry to be a grammar Nazi but I noticed you misuse the present perfect very often. Present perfect (I have discovered) is to be used only when you speak about present, when you are talking about something what happened in the past, use the past simple (I discovered):)