Quick question about how provisioning of Virtual Interfaces/IP's is supposed to happen.

Help! (Home for newbies)
1

I’ve used Webmin for years, so bear with me here. :slight_smile:

I’ve set up on FreeBSD 6.x, and it’s on me to configure this, which is fine. I can do things manually without a problem, ie I go into Network, create a virtual interface/IP, then go back, create a new site and use that IP. No sweat.

I also see that I can pick which network interface to use in the module configuration (good), and set a base number for virtual interface (good), then in templates and resellers, I can assign a range of IP’s.

Here’s where I’m getting stuck. If I go in as either an admin or reseller, go to create a new site, the only options that appear are the default shared IP, or enter a virtual IP address. That’s fine, but the point (I presume?) of being able to select an assignment range is that either via template or reseller account, the user is limited in which IP’s can be used here. Am I wrong about this? I would presume rather than a text box here, the UI element should be a drop-down of available IP’s that account could choose from.

The bigger gotcha however is upon attempting to create the new site. It complains that the IP address isn’t already on the system. Well of course it isn’t…it hasn’t been used yet. I thought that was the point of selecting a physical interface, so that Virtualmin would create virtual interfaces as-needed and bring them up, right? Or am I just confused on that point?

2

Pfft. "Home for Newbies". New to Virtualmin, but this is about to get advanced. :slight_smile:

I can’t hang around much longer waiting on the solution to this, but I went digging for it myself. The relevant code is in domain_form.cgi:

[pre]

Show IP address allocation section

$resel = $parentdom ? $parentdom->{‘reseller’} :

     &reseller_admin() ? $base_remote_user : undef;

if (!$aliasdom && &can_use_feature("virt")) {

    print &ui_table_row(&hlink($text{'form_iface'}, "iface"),

            &virtual_ip_input(@cantmpls, $resel),

            undef, @tds);

    }

[/pre]

So in plain english, "if we aren’t an alias domain, and we are allowed to use this feature (per the function can_use_feature), then print a ui_table_row, first field is a help lnk, for interface, second field is virtual_ip_input, where my interest lies. It calls sub virtual_ip_input, and passes some values along for testing.

Well, this looks like where things are going wrong. In that sub, there’s a few tests, if ($config{‘all_namevirtual’}) doesn’t apply to us, the next section has a statement that basically says:

[pre]

if ($tmpl->{‘ranges’} ne “none”) { $anyalloc++; }

else { $anychoose++; }

}

[/pre]

If in your template there are ranges defined, then increment $anyalloc, otherwise increment $anychoose. In our situation, we want to increment $anyalloc (I think?) so that a drop-down list will get rendered. The way to do that is to define a range in the template.

Problem is, that doesn’t work. I’ve defined ranges in the template, and somehow this conditional statement is still failing. Even worse, I’ve tried commenting the above out, and replacing it with just:

[pre]

$anyalloc++;

[/pre]

What then happens is the form fails to finish rendering. That doesn’t work. So I must somehow be legitimately failing to populate ranges in the $tmpl scalar.

Can somehow lend me a hand here? Should I be submitting a bug report on this?

3

Hey Tony,

Should I be submitting a bug report on this?

Of course! If you had to look at code to figure something out, it’s a bug, even if it’s working as we intended it (that just means we intended horribly wrong, because it isn’t intuitive at all…sometimes Jamie takes a little convincing that we’re wrong when things work the way he intended, but he comes around eventually). In this case, I believe it’s actually a bug and not just a stupid UI decision.

4

BTW-You FreeBSD users are too damned smart for your own good (but we’re happy to have you poking around in the code, if you feel the urge). :wink:

5

Pfft. "Home for Newbies". New to Virtualmin, but this is about to get advanced. :slight_smile:

I can’t hang around much longer waiting on the solution to this, but I went digging for it myself. The relevant code is in domain_form.cgi:

[pre]

Show IP address allocation section

$resel = $parentdom ? $parentdom->{‘reseller’} :

     &reseller_admin() ? $base_remote_user : undef;

if (!$aliasdom && &can_use_feature("virt")) {

    print &ui_table_row(&hlink($text{'form_iface'}, "iface"),

            &virtual_ip_input(@cantmpls, $resel),

            undef, @tds);

    }

[/pre]

So in plain english, "if we aren’t an alias domain, and we are allowed to use this feature (per the function can_use_feature), then print a ui_table_row, first field is a help lnk, for interface, second field is virtual_ip_input, where my interest lies. It calls sub virtual_ip_input, and passes some values along for testing.

Well, this looks like where things are going wrong. In that sub, there’s a few tests, if ($config{‘all_namevirtual’}) doesn’t apply to us, the next section has a statement that basically says:

[pre]

if ($tmpl->{‘ranges’} ne “none”) { $anyalloc++; }

else { $anychoose++; }

}

[/pre]

If in your template there are ranges defined, then increment $anyalloc, otherwise increment $anychoose. In our situation, we want to increment $anyalloc (I think?) so that a drop-down list will get rendered. The way to do that is to define a range in the template.

Problem is, that doesn’t work. I’ve defined ranges in the template, and somehow this conditional statement is still failing. Even worse, I’ve tried commenting the above out, and replacing it with just:

[pre]

$anyalloc++;

[/pre]

What then happens is the form fails to finish rendering. That doesn’t work. So I must somehow be legitimately failing to populate ranges in the $tmpl scalar.

Can somehow lend me a hand here? Should I be submitting a bug report on this?

6

Pfft. "Home for Newbies". New to Virtualmin, but this is about to get advanced. :slight_smile:

I can’t hang around much longer waiting on the solution to this, but I went digging for it myself. The relevant code is in domain_form.cgi:

[pre]

Show IP address allocation section

$resel = $parentdom ? $parentdom->{‘reseller’} :

     &reseller_admin() ? $base_remote_user : undef;

if (!$aliasdom && &can_use_feature("virt")) {

    print &ui_table_row(&hlink($text{'form_iface'}, "iface"),

            &virtual_ip_input(@cantmpls, $resel),

            undef, @tds);

    }

[/pre]

So in plain english, "if we aren’t an alias domain, and we are allowed to use this feature (per the function can_use_feature), then print a ui_table_row, first field is a help lnk, for interface, second field is virtual_ip_input, where my interest lies. It calls sub virtual_ip_input, and passes some values along for testing.

Well, this looks like where things are going wrong. In that sub, there’s a few tests, if ($config{‘all_namevirtual’}) doesn’t apply to us, the next section has a statement that basically says:

[pre]

if ($tmpl->{‘ranges’} ne “none”) { $anyalloc++; }

else { $anychoose++; }

}

[/pre]

If in your template there are ranges defined, then increment $anyalloc, otherwise increment $anychoose. In our situation, we want to increment $anyalloc (I think?) so that a drop-down list will get rendered. The way to do that is to define a range in the template.

Problem is, that doesn’t work. I’ve defined ranges in the template, and somehow this conditional statement is still failing. Even worse, I’ve tried commenting the above out, and replacing it with just:

[pre]

$anyalloc++;

[/pre]

What then happens is the form fails to finish rendering. That doesn’t work. So I must somehow be legitimately failing to populate ranges in the $tmpl scalar.

Can somehow lend me a hand here? Should I be submitting a bug report on this?

7

Good news is that it wasn’t a functional bug, it was me thinking too hard on the Module Config. I chose to have all Apache sites be “name-based only”, which in my head made sense - of course they’re all name based! :stuck_out_tongue: No, no they aren’t. if you’re assigning any static IP sites (such as SSL), thay aren’t all name-based, just most of them. :slight_smile: There’s a difference.

Should probably think about setting a boolean in JavaScript to keep users from doing what I did. If they have the option to create SSL sites there, then have a popup that basically warns them that they are contradicting themselves -

“You just told me you wanted to create SSL-based sites, and now you’re telling me you want all Apache sites to be name-based. Which way do you want it already???” :slight_smile:

Anyhoo, it works now. You got the worst kind of FreeBSD user - one that knows perl, and isn’t afraid to use it. :slight_smile: You actually got a triple whammy, FreeBSD, perl coder, and one that has done a couple of custom webmin/usermin modules way back when, so I have a rough (VERY rough) understanding of how all of this is supposed to functions, webmin API’s, etc. :slight_smile: