osu-net / cyder Goto Github PK

Any test related to IPv6 has the same error:

ValidationError: [u'The router options <stuff> is not a valid ip list']

Not sure what the exact issue is but this might be resolved by @fridgei's upcoming pull request.

This is the error raised by several tests related to Static Interface key values, including AuxAttrTests and StaticInterTests.test1_create_basic. Resolving this issue might be as simple as figuring out what _check_is_digit is supposed to do, and implementing it.

We have so many open issues that I have to click to another page to see them all. This is unacceptable. Resolve issues until they will all fit on one page.

Example: Ctnr objects have a many to many relationship with Users, but there isn't a good widget for adding multiple users. Therefore the Ctnr create view should redirect to the "add user to ctnr" page after creation.

This should be implemented for all views with many to many relationships.

They stick out past their container when selected. The should behave the same as system, dns and dhcp. There is probably some rogue css that slipped by. I would start by looking in base.scss. Don't edit base.css by the way. The .scss creates the css.

Finish Cyder API.

Issue transported from Chili:

zone_domain includes relationships to zones and domains that don't exist

SELECT zone_domain.domain
FROM zone_domain
WHERE (
SELECT count( * )
FROM domain
WHERE domain.id = zone_domain.domain
) = 0

returns 62 results involving missing domains, also, there is one relationship involving zone 29, which does not exist

I don't know at this time whether there are other broken relationships that need to be fixed.

I navigate to the list view, and all I see is the Campus site, even though I've created two new sites and confirmed that they exist in the database.

Possibly related to #32?

As far as I can tell, it's imaginary. Should we get rid of _aa_dns_servers() in cyder/cydhcp/keyvalue/base_option.py?

type object 'Ctnr' has no attribute 'search_fields'
When using filters in the ctnr list page.

"Sometimes a zone needs to have a config statement outside of [Cyder]'s control. This patch facilitates that."

Want to know whether we should backport this feature from Mozilla inventory.

mozilla/inventory@d766ec0

This was from the chili repo, I assume it's an enhancement to add a network wizard.

After creating a ctnr or even for existing ctnr's, you cannot add a user to it.

Deletes on click without conformation and without redirect.

To reproduce:
Switch to ctnr, delete it. Ctnr dropdown will still contain that ctnr and super_user will still be on the ctnr.

This causes errors throughout cyder whenever a table is being passed through json. The page will automatically hang every time.

I think we're probably at a wall re: DNS migrations, but there is at least one clear improvement that can be made to DHCP migrations. migrate_zone_reverse takes a huge chunk of time, the reason being that, every time a new reverse domain is created, reassign_reverse_ptrs gets called. When we create a set of domains, pointers will be assigned to the top level domain, and then get reassigned to subdomains, resulting in a lot of duplicated effort.*

I don't know whether this issue is a real priority, but if we need to do a lot of migrations leading up to the deployment deadline, it could be worth our time.

*Update: This doesn't actually matter that much. I think the real reason why reassign_reverse_ptrs takes forever is because there's at least 11000 static interfaces, and name_to_domain hits the database for each one. It could also be obj.save(), too.

Returns top 2 parents and ignores the rest.

Fix front end authentication.

To reproduce the performance issue, go to:
https://cyder.nws.oregonstate.edu/core/ctnr/118/

For reference, this is the zone.core Ctnr view, with a full(?) migration of reverse domains.

Notice that visiting this page makes 674 queries. I doubt that we need to make that many queries, so we should look into reducing it, possibly via the queryset API's select_related call. Note that sometimes, using select_related can create very complex queries that actually reduce performance, so we need to ensure that we use it in such a way that does in fact improve performance.

Looking at the routers tests, cyder/cydhcp/keyvalue/base_option never actually checks for valid ipv6 address.

To reproduce: Run SystemViewTests
Guest users are able to create, delete, and update despite not having permission. In cyder/base/tests/test_view_template.py, even if the user does not have permission to do the action, the request is successful. Not sure yet whether this is happening because we turned permissions off at some point, or if it's something more sinister.

This is an issue for other views besides System views, as well.

Write tests for Cyder's API.

To reproduce: Run CNAMETests
These tests ensure that a PTR record does not point to a CNAME, in compliance with RFC 1034 (maybe 1912?). There /are/ checks in place in the PTR and CNAME models, but this code has been commented out because there are/were preexisting records in Maintain that violate this rule. We need to verify that it is safe to reintroduce this code so that these tests will pass.

In other words, if we reintroduce the code and attempt a migration, and everything goes fine, then we're good to go.

Configure and test django_cas (django-cas2). Requested access to campus CAS server, won't get access until Monday. I'll check out what we have in the meantime.

Traceback (most recent call last):
  File "/home/ch/cyder/cyder/cydhcp/vlan/tests.py", line 120, in test_related_networks
    self.assertEqual(v1.get_related_networks(), set([n9]))
AssertionError: Items in the second set but not the first:
<Network 223.0.0.0/10>

Not sure how this test is supposed to work. I can't see anything in the logic that might produce the desired result. Do we need to implement this feature from scratch?

Module has no attribute MX.
Looks like it is just a bad import.

Adding workgroups and ranges to be displayed in the detail view.

Probably not. Most of the "users" in maintain.users are from autoreg if I remember correctly. Need to investigate and update migration query/function.

Many dns objects are children in the domain detail view rather than having their own detail view. There should be urls for all objects to their own detail view though. For example, soa/1 should send you to the domain detail page that contains soa:id=1.

A bad chain of imports.

Not sure if this issue is a result of a broken migration or something, but the user detail view doesn't display the correct CtnrUser relationships.

When I go to create a new range, I need to select a network from a dropdown list. However, the dropdown is unsorted, and there are ~600 networks to choose from. This makes the interface difficult to use.

Please update the cyder UI image in the ReadMe file. The cyder man and dancing kid have been removed from the actual UI we should update it.

To reproduce, run the CtnrViewTests.
AttributeError: Cannot set values on a ManyToManyField which specifies an intermediary model. Use ctnr.CtnrUser's Manager instead.

I believe this is an issue for many different views for models that use similar ManyToMany fields. It's worth noting that this is /not/ a problem for SystemViewTests, which were written first.

There are many instances of code that does not adhere to our standards. For instance, run the following command:

check.py cyder/* | grep -v migrations.000

We can't fix ALL of these issues (example: import *) but it's a start. For reference, our official coding standards can be found in README.md

Needs to be styled and have deselect and reset options at the tops. Also needs to be mobilefied.

There are some tests that autodiscovery doesn't find:

cyder/cydns/api/tests/kv.py
cyder/cydns/api/tests/basic.py

These tests raise a familiar error, ImportError: No module named test_views_template. Are they worth salvaging?

In the SOA list view, there is no way to click on an soa to get to its detail view. When you try to do it manually, /soa/1, it traces back to base detail view and throws an 'obj' is undefined error.

Allow users to report bugs.

A specific case is when you are in Ctnr detail view and click edit. It pushes the add user form down and replaces its contents with the new form.

Both are quite broken. When trying to delete, the delete works but the page does not redirect properly and we get an list index out of range error. Update does absolutely no nothing because it is calling js the reveals a hidden form, but that form does not exist on the page.

Note: In the following bug report, "update form" refers to the grayish box with input fields that allows one to update a single row's fields; "list view" refers to the type of display seen (e.g.) on this page in which rows are shown in a list.

In the web interface, when I click the update button in any row of a list view, the update form box slides down but none of the fields are filled with their current value. For instance, if I go to http://localhost:8000/core/system/ and click the update button in some row, the update box appears with the heading "Updating System", but every field's text box is blank and behaves as I would expect a blank text box to behave.

For some reason, this bug does not occur when in the detail view, for instance at http://localhost:8000/core/system/1.

A git-bisect shows that 5ac7293 was the commit that introduced this bug. Reverting it at the tip of master currently resolves this issue.

Show host history in UI

Maintain's database currently stores some dhcpd options that don't conform to the specifications given in the dhcpd-options man page and elsewhere. The following options in the database currently specify one or more FQDNs, even though specs say they should only hold IPs:

ntp-servers
time-servers
domain-name-servers

This may mean one or more things:

1. ISC dhcpd automagically resolves domains if necessary. (Not sure if that makes sense.)
2. Maintain resolves the domains before giving the options to dhcpd. (Ditto.)
3. ISC dhcpd has been dying without us noticing. (Very unlikely.)

Why does Maintain store these apparently nonconforming options?

The bigger question: Should maintain_migrate (a.) allow these apparently nonconforming options as-is, (b.) make them conform, or (c.) die when they don't pass validation?

(The current behavior is c., as far as I can tell.)

According to the Django docs, a CharField, TextField, or EmailField should not specify null=True—the empty string already represents "no data", so allowing NULL is unnecessary and confusing. We have no good reason for breaking this guideline.

To reproduce: Run ViewTests.
This group of tests ensure that a validation error is raised in the following cases:

2. Give an A/PTR/StaticInterface private IP and the public view.
   -clean, save, ValidationError raised
3. Give an A/PTR/StaticInterface private IP and the public and private view.
   -clean, save, ValidationError raised

It seems that AddressRecords, StaticInterfaces, and PTRs might each need a custom clean_views method as outlined in the ViewMixin. Or possibly they could inherit it from a common ancestor? I dunno.

If a given user does not exist, and a container administrator attempts to add them to a container, they should be created and added to the container, even if they can't log in. (Potential extension of this: display a confirmation box if the user does not exist in LDAP/whatever.)

There needs to be a way to delete users from containers. Furthermore, there needs to be a way to delete a user, and remove them from all containers.

Unneeded users should be deleted regularly to keep the database clean. Some policies we suggested:

• Delete a user as soon as they no longer have permissions to any container.
• Delete users without any permissions regularly, such as at the end of each term.

Users' first name, last name, and e-mail will also need to be updated regularly. Some policies we suggested:

• Update the user when they log in
• Update the user when their permissions change

Research Tasty Pie url: http://tastypieapi.org/

For the following ISC dhcpd options, hostnames are allowed as well as IPs:

ntp-servers
domain-name-servers
netbios-name-servers
time-servers (distinct from ntp-servers)
log-servers
next-server
cookie-servers
finger-server
font-server
impress-server

However, for all of these options, the cydhcp.keyvalue.base_option.CommonOption class's option validation methods (aa*) call IP validation functions rather than IP-or-domain validation functions. For instance, _aa_time_servers validates the option as a list of IPs, rather than a list of IPs and domains.

(By the way, several sources say domains can include underscores but hostnames can't. @murrown says we should allow underscores in hostnames "contrary to existing standards". I'm tentatively allowing them until someone tells me not to.)